Backend

Data

CRUD against collections. The dashboard renders the same records the agent writes.

Tools

  • data.list lists a collection. The response includes related labels for rel and file fields.
  • data.get returns one record by id.
  • data.create and data.update merge into the existing JSON object.
  • data.query filters by exact field matches.
  • data.delete returns 409 while other records still reference the target.
  • data.revisions shows prior values and schema change checkpoints.

Who can see a row

Records created through the customer API are stamped with createdBy. Collection access decides whether the publishable key can list everyone, only signed-in people, only the owner, or nobody. MCP and the hosted admin still see the full collection. The publishable key uses the published schema. A new collection is already live; a draft edit to a published collection is not.

Retired fields

Record JSON keeps keys after a field is removed from the live schema. Updates do not strip those keys, so a restore can bring them back.

Search

data.query filters by exact field matches. REST list accepts ?q=, a case-insensitive substring over the stored JSON — not a structured query.

REST

Same records over HTTP: GET/POST /v1/<projectId>/data/:collection and GET/PATCH/DELETE /v1/<projectId>/records/:id. Full table on the REST API page.

Relations and files

Rel fields must contain an existing id in the target collection. File fields must contain a file id from files.upload. Look ids up before you write.