Custom App & Database lookup cookbook

Use an application API key in Authorization: Bearer YOUR_API_KEY. Pass the central organisation UUID in X-AutoAppy-Workspace. Writes require a read/write key. Never embed a key in frontend source.

Choose a database, table and column

1. GET /api/v1/platform/organisations/{workspace}/data/databases returns available databases in data.

2. GET /api/v1/platform/organisations/{workspace}/data/bootstrap?database_id={database} returns the selected database tables in data.tables.

3. GET /api/v1/platform/organisations/{workspace}/data/tables/{table} returns data.fields. Use each column's stable key in filters and values; label is its display header, type controls validation, required marks create requirements, and options lists select choices.

4. GET .../tables/{table}/records lists rows. q searches the record title only. A column lookup uses filters.

Find Raj by title AND email

curl --get 'https://api.autoappy.com/api/v1/platform/organisations/WORKSPACE/data/tables/TABLE/records' \

  -H 'Authorization: Bearer YOUR_API_KEY' \

  -H 'X-AutoAppy-Workspace: WORKSPACE' \

  --data-urlencode 'filters[0][field]=name' \

  --data-urlencode 'filters[0][operator]=eq' \

  --data-urlencode 'filters[0][value]=Raj' \

  --data-urlencode 'filters[1][field]=email' \

  --data-urlencode 'filters[1][operator]=eq' \

  --data-urlencode 'filters[1][value]=raj@example.com' \

  --data-urlencode 'per_page=30'

Illustrative response (identifiers are placeholders):

{"data":[{"id":"ROW","name":"Raj","version":1,"values":{"email":"raj@example.com"}}],"total":1,"current_page":1,"last_page":1,"per_page":30}

data contains this page's accessible records; total is the matching count; current_page and last_page control pagination. id selects a row; version is required as expected_version for safe update/delete. values maps schema keys to typed values. No match is a successful response with data: [] and total: 0, not an API error.

Optional query parameters: q (title contains), external_key (exact external key), status (active/archived/all; active default), sort (schema key or name/created_at/updated_at/id), direction (asc/desc), page (1+), per_page (1–100), filters (up to ten AND conditions). Each filter requires field and operator; value is required by the selected typed comparison, except empty. Operators: eq/ne/gt/gte/lt/lte/contains/empty. Relations require an exact record ID; JSON columns cannot be filtered. An invalid/inactive field returns 422; it never silently becomes an empty result.

You can also send filters as one URL-encoded JSON query parameter: filters=[{"field":"email","operator":"eq","value":"raj@example.com"}]. Invalid JSON returns 422 with a filters error.

Insert and update

{"name":"Raj","values":{"email":"raj@example.com","age":28}}

POST this body to the records list URL. For PATCH /records/{record}, send only changed fields plus expected_version from the previous read. A version mismatch returns 409; reread and reconcile. Do not blindly retry a write. Contact tables can additionally require expected_contact_version.

To retrieve values by column headers in workflows, select Return values by → Column headers. The adapter adds header_values while retaining original data.values. Duplicate labels are rejected; schema keys are recommended for stable automation. Iterate pages using last_page to retrieve all rows.

General errors and pagination

All example IDs are placeholders. Look them up using your own authorised connection. 401 requires renewed authentication; 403 requires checking application, read/write permissions and workspace; 404 means unavailable resource; 422 contains invalid-field details; 429 requires respecting Retry-After. Dropdowns display the current API page; Map Data accepts an exact identifier from a later page or previous action. Lists never broaden permissions to fill choices.