DOCUMENTATION / DYNAMIC ROUTES
Request conventions, CRUD, pagination, search, filters, execution, array operations, and exports.
Current availability: dynamic functions are paused in AutoTable. This article preserves the earlier route reference. Use a workflow or a saved pipeline for supported executable logic.
Every table you define in AutoTable automatically gets a ready-to-use REST API. You do not write any server code: the table's fields decide what is valid, and its settings decide who may call each route. This guide shows how to create, read, update, delete, search, and run saved logic through those routes.
All dynamic routes live under one base path and work the same way for every table. You choose the table with schemaName, choose the action with the HTTP method and path, and send JSON. Here is the full record lifecycle for an orders table.
# 1. Create
POST /api/v1/{tenantSlug}/{projectSlug}/dynamic/?schemaName=orders
{ "orderNumber": "A-1042", "status": "draft", "total": 184.5 }
# 2. List (paginated)
GET /api/v1/{tenantSlug}/{projectSlug}/dynamic/page?schemaName=orders&page=1&limit=20
# 3. Read one
GET /api/v1/{tenantSlug}/{projectSlug}/dynamic/66f10c1a12ab34cd56ef7890?schemaName=orders
# 4. Update only the fields that change
PATCH /api/v1/{tenantSlug}/{projectSlug}/dynamic/66f10c1a12ab34cd56ef7890?schemaName=orders
{ "status": "paid" }
# 5. Delete
DELETE /api/v1/{tenantSlug}/{projectSlug}/dynamic/66f10c1a12ab34cd56ef7890?schemaName=ordersEvery URL has the same five parts. Once you can read one, you can read them all.
https://<host>/api/v1/acme/storefront/dynamic/page?schemaName=orders&page=1&limit=20
└──┬───┘ └───────────┬───────────┘ └──┬──┘ └─┬─┘ └─────────────────┬─────────────────┘
server tenant + project dynamic route query parameters
(which app) group (what) (which table + options)Start from what you want to do. The articles in this guide follow the same groups.
POST / creates one record, POST /multiple creates many. PATCH /:id and PATCH /multiple update; DELETE /:id and DELETE /multiple remove.
GET /page for paginated, filterable, sortable lists. GET /search for text search, GET /filter for typed filters, GET /table-source for page tables.
GET /:id loads one record. GET /selection returns label/value options for selectors.
GET /pipeline runs a saved report, POST /workflow/:workflowName runs a manual workflow, GET /execute runs a dynamic function, GET /api calls a saved external API.
The /:schema/:id/array/:field routes add, update, reorder, and delete rows of an embedded array field.
POST /export returns an XLSX file of the records you select.
The server checks the same things in the same order for every dynamic route. When a call fails, the error usually tells you which checkpoint stopped it.
The tenant and project slugs in the path are resolved first. Every read and write is isolated to that project.
schemaName loads the table's fields and settings. Without it you get 400 Schema name is required.
The route's settings (or the saved pipeline, workflow, function, or API) decide whether the call must be signed in, needs a role, or is disabled.
Rate limits and body-size limits protect the server. Exceeding them returns an error before any data is touched.
The body is checked against the table's field rules, and configured workflows run with the operation.
Writes return { status, message, data }. Reads return the records directly or a paginated items envelope.
Read in this order and stop once you can build what you need.
Build a correct URL and understand how schemaName selects the table.
Make routes public or private, send the right headers, and understand responses and errors.
Create, list, read, update, and delete records - the routes you will use most.
Search, filter, table sources, pipelines, workflows, functions, and external APIs.
Embedded array rows, XLSX export, limits, and the complete route list.
A connected foundation for the things you want to build.