The API

Everything the web app shows is available over HTTPS, under the same permissions as the person signing in. Use it to pull records into your own systems on a schedule, or to write records in from another tool.

Settings → API shows your base URL and the key you need, with copyable examples.

The API Documentation page under Settings, showing the base URL, the authorisation header required, and example requests for forms and submissions. — Settings → API. The examples on this page are live for your organisation.

Signing in

Requests carry a Bearer token belonging to a member of your organisation. Get one by signing in with an email and password:


curl -X POST "$BASE_URL/auth/v1/token?grant_type=password" \
  -H "apikey: $PUBLIC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"integrations@example.com","password":"…"}'

The response includes access_token. Send it as Authorization: Bearer <access_token> and apikey: $PUBLIC_KEY on every request. Tokens expire after an hour; the response also includes a refresh_token to get a new one without the password.

Create a dedicated member for integrations — integrations@yourcompany — with a View grant on the forms it reads and nothing more. Its token then cannot do anything the integration should not, and revoking it is deactivating one member.

Reading

The API is a REST interface over the same tables the app uses. Filters go in the query string.

Forms


curl "$BASE_URL/rest/v1/forms?select=id,name,status&order=name" \
  -H "apikey: $PUBLIC_KEY" -H "Authorization: Bearer $TOKEN"

A form’s fields — the keys you will see as column names:


curl "$BASE_URL/rest/v1/form_fields?form_id=eq.$FORM_ID&select=key,label,field_type&order=sort_order" \
  -H "apikey: $PUBLIC_KEY" -H "Authorization: Bearer $TOKEN"

Records — everything on one form changed since a point in time, which is the shape a scheduled pull needs:


curl "$BASE_URL/rest/v1/submissions?form_id=eq.$FORM_ID&updated_at=gt.2026-09-01T00:00:00Z&order=updated_at&select=id,status,submitted_at,updated_at,data" \
  -H "apikey: $PUBLIC_KEY" -H "Authorization: Bearer $TOKEN"

Each record’s data is an object keyed by field key. Repeatable sections are arrays inside it. Deleted records do not appear.

Useful filters: status=eq.approved, submitted_at=gte.<date>, limit=500&offset=0 for paging. Any column can be filtered with eq, neq, gt, gte, lt, lte, in.

Writing

Records can be created and updated by POST and PATCH to /rest/v1/submissions, under the same rules as the app: the token’s member must be able to collect on the form, and cannot set a record approved. The examples on Settings → API show the exact body.

Exporting

The export the web app offers is also a call, returning a file:


curl -X POST "$BASE_URL/functions/v1/export-data" \
  -H "apikey: $PUBLIC_KEY" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"form_id":"'$FORM_ID'","format":"csv"}'

Limits and manners

Page with limit and offset; pull by updated_at rather than everything every time.
A token is a person’s session. Keep it out of source control and out of logs.
If you need something the API does not expose, write to customer.service@firedragontech.com. We will help you get the data you need.