OZ
ozmishow
  • Emre
  • Collection
  • mustafa
  • Ufuk
  • Press
  • CANSU
  • Furkan
  • Zeyno
  • Osman
  • Hilmies
  • Home
  • EN
  • TR
  • Emre
  • Collection
  • mustafa
  • Ufuk
  • Press
  • CANSU
  • Furkan
  • Zeyno
  • Osman
  • Hilmies
  • Home
THEME
Dynamic routes overviewBase URL and project contextRoute policy and request conventions
Create a recordCreate multiple recordsList all recordsPaginated recordsSelection optionsGet a record by IDUpdate a recordUpdate multiple recordsDelete a recordDelete multiple records
Search recordsFilter recordsTable sourceExecute a saved pipelineTest a pipelineExecute a workflowExecute a dynamic functionExecute a dynamic API
Export recordsAdd an array rowUpdate an array rowReorder array rowsDelete an array row
Responses and errorsLimits, security, and idempotencyComplete route reference

Dynamic routes overview

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.

Your table is already an API

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.

http
# 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=orders

Reading a request URL

Every URL has the same five parts. Once you can read one, you can read them all.

text
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)

Which route do I need?

Start from what you want to do. The articles in this guide follow the same groups.

Save data

POST / creates one record, POST /multiple creates many. PATCH /:id and PATCH /multiple update; DELETE /:id and DELETE /multiple remove.

Show a list or table

GET /page for paginated, filterable, sortable lists. GET /search for text search, GET /filter for typed filters, GET /table-source for page tables.

Show one record or a dropdown

GET /:id loads one record. GET /selection returns label/value options for selectors.

Run saved logic

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.

Edit a list inside a record

The /:schema/:id/array/:field routes add, update, reorder, and delete rows of an embedded array field.

Download data

POST /export returns an XLSX file of the records you select.

What happens on every request

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.

1. Find the project

The tenant and project slugs in the path are resolved first. Every read and write is isolated to that project.

2. Load the table

schemaName loads the table's fields and settings. Without it you get 400 Schema name is required.

3. Check access

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.

4. Apply limits

Rate limits and body-size limits protect the server. Exceeding them returns an error before any data is touched.

5. Validate and run

The body is checked against the table's field rules, and configured workflows run with the operation.

6. Respond

Writes return { status, message, data }. Reads return the records directly or a paginated items envelope.

Suggested learning path

Read in this order and stop once you can build what you need.

1. Base URL and project context

Build a correct URL and understand how schemaName selects the table.

2. Route policy and request conventions

Make routes public or private, send the right headers, and understand responses and errors.

3. Records and CRUD

Create, list, read, update, and delete records - the routes you will use most.

4. Query and execution

Search, filter, table sources, pipelines, workflows, functions, and external APIs.

5. Arrays, export, and reference

Embedded array rows, XLSX export, limits, and the complete route list.

  • Dynamic routes overview
  • Your table is already an API
  • Reading a request URL
  • Which route do I need?
  • Save data
  • Show a list or table
  • Show one record or a dropdown
  • Run saved logic
  • Edit a list inside a record
  • Download data
  • What happens on every request
  • 1. Find the project
  • 2. Load the table
  • 3. Check access
  • 4. Apply limits
  • 5. Validate and run
  • 6. Respond
  • Suggested learning path
  • 1. Base URL and project context
  • 2. Route policy and request conventions
  • 3. Records and CRUD
  • 4. Query and execution
  • 5. Arrays, export, and reference
ozmishow
  • Emre
  • Collection
  • mustafa
  • Ufuk
  • Press
  • CANSU
  • Furkan
  • Zeyno
  • Osman
  • Hilmies
  • Home
  • EN
  • TR
© 2026 ozmishow