REST API

The Lotics API gives you programmatic access to everything in your workspace. Create records, query data, trigger workflows, generate documents, and receive real-time notifications, all through a standard REST interface with an OpenAPI 3.1.0 specification.

Overview

The Lotics API follows REST conventions: resources are nouns, HTTP methods are verbs, and responses use standard status codes. Every entity you interact with in the Lotics interface (tables, records, views, workflows, document templates, files) is available through the API. The base URL is https://api.lotics.ai/v1.

An OpenAPI 3.1.0 specification is published at https://api.lotics.ai/v1/openapi.json. You can import this spec into tools like Postman, Insomnia, or any OpenAPI-compatible code generator to get typed client libraries in your preferred language. The spec stays in sync with the API. When new endpoints ship, the spec updates automatically.

All requests and responses use JSON. Dates are ISO 8601 strings in UTC. Record field values follow the same types as the Lotics interface: text, number, date, select, multi-select, linked records, files, and computed fields (formula, rollup, lookup).

Authentication

API requests are authenticated with organization-scoped API keys. Each key is scoped to a single organization and inherits the permissions of the team member who created it. Keys use the format ltk_ followed by 48 characters (e.g., ltk_vAJZYFb9WrF94Z3OjpdZgxjc...). Only admins can create API keys.

Create API keys in Settings → API Keys. Each key has a name for identification (e.g., "Production sync", "CI/CD pipeline"). Keys are shown once at creation. Store them securely. If a key is compromised, disable it immediately from Settings and create a new one.

Include the key in the x-api-key header: x-api-key: ltk_your_key_here. Requests without a valid key receive a 401 Unauthorized response. Disabled keys receive a 403 Forbidden response. API key authentication is currently supported for table, record, field, and view endpoints. Other endpoints (workflows, document templates, apps) use session-based authentication.

Available endpoints

The API provides full CRUD operations for all primary entities, plus specialized operations like record aggregation, document generation, and global search. Below is a summary of available resource endpoints.

Each endpoint supports standard query parameters for filtering and pagination. Record queries support field-level filters, sorting by any field, and server-side pagination with cursor-based navigation for consistent performance at any table size.

ResourceOperationsNotes
TablesList, Create, Get, Update, Delete, CloneIncludes field definitions. Clone duplicates structure and optionally data.
FieldsCreate, Update, DeleteAdd or modify fields on existing tables. Supports all field types including computed fields.
RecordsQuery, Get, Get by IDs, Create, Update, Delete, AggregateQuery supports filters, sorts, pagination. Aggregate returns counts, sums, averages by field.
ViewsList, Create, Get, Update, DeleteViews store filter, sort, field visibility, and color rule configurations.
WorkflowsList, Create, Get, Update, DeleteIncludes trigger configuration, step definitions, and execution history.
Document TemplatesList, Create, Get, Update, Delete, GenerateGenerate produces a document (PDF, Excel) from a template and record data.
AppsList, Create, Get, Update, DeleteApps are custom interfaces built on top of tables.
CommentsList, Create, Update, DeleteComments are attached to records. List supports filtering by record.
FilesUpload, Read, DeleteUpload files to attach to records. Read returns signed download URLs.
Connected AccountsList, Request, DeleteQuery connected OAuth accounts. Request initiates a new OAuth flow.
SearchGlobal searchSearch across all tables and records in the organization.

Rate limits and pagination

The API enforces rate limits to ensure fair usage and consistent performance. Standard limits are 100 requests per second per API key. Burst capacity allows short spikes above this limit. Rate-limited requests receive a 429 Too Many Requests response with a Retry-After header indicating when to retry.

All list endpoints use cursor-based pagination. Responses include a next_cursor field when more results are available. Pass this value as the cursor query parameter in the next request. Page size defaults to 100 records and can be adjusted up to 1,000 with the limit parameter. Cursor-based pagination ensures consistent results even when records are created or deleted between requests.

Record queries are executed server-side with the same filter engine used by the Lotics interface. This means complex filters (nested AND/OR conditions, linked record lookups, date comparisons) perform the same way through the API as they do in the app. There is no client-side filtering overhead regardless of table size.

Webhook events

Register webhook endpoints to receive real-time notifications when data changes. Lotics sends an HTTP POST to your URL within seconds of a change occurring. Events include the full record data before and after the change, so you can react to specific field updates without polling.

Available event types include record.created, record.updated, record.deleted, workflow.completed, and workflow.failed. Each webhook registration can filter by table and event type so you only receive relevant notifications. Webhook payloads include a signature header for verification.

Failed deliveries are retried with exponential backoff for up to 24 hours. You can view delivery logs and manually retry failed deliveries from Settings, Webhooks. If an endpoint consistently fails, Lotics disables it and sends an email notification to the organization admin.

MCP Server and use cases

Lotics also provides a Model Context Protocol (MCP) server that exposes the same capabilities as the REST API through the MCP standard. This allows AI assistants and LLM-based tools to interact with your Lotics data directly. See the dedicated MCP Server documentation page for setup instructions and available tools.

Common API use cases include syncing data between Lotics and external systems (ERP, CRM, e-commerce), building custom dashboards that pull live data from Lotics tables, automating record creation from external events (form submissions, payment confirmations, shipping updates), and generating reports by querying and aggregating record data programmatically.

The API is the same interface that the Lotics web application uses internally, so every feature available in the UI is also available through the API. There are no second-class endpoints or limited capabilities.

Frequently asked questions

Yes. Standard rate limits are 100 requests per second per API key with burst capacity for short spikes. Rate-limited requests receive a 429 response with a Retry-After header. Contact support if your use case requires higher limits.

Yes. The workflows endpoint supports full CRUD. You can create triggers, define steps (including conditionals, loops, and AI actions), and deploy workflows entirely through the API. Workflow execution history is also available via the API.

Use the Files upload endpoint with a multipart/form-data request. The response returns a file ID that you can then assign to a file field when creating or updating records. File download URLs are signed and time-limited for security.

Yes. The OpenAPI 3.1.0 spec is available at https://api.lotics.ai/v1/openapi.json. Import it into tools like openapi-generator, Postman, or any OpenAPI-compatible client to generate typed SDKs in TypeScript, Python, Go, Java, and other languages.

Create a separate organization for development and testing. API keys are organization-scoped, so your test key will only access test data. There is no additional cost for development organizations.