Data API (v2)

One REST resource per table, for programs and for SvGrid's createRestDataSource, which reads and writes it with no adapter.

Signing in

The same credentials as the rest of the API:

• a signed-in browser session
• an API token (Profile → API tokens), sent either way:
  • Authorization: Basic base64(email:token)
  • API-KEY: <token>

A token works only in the workspace it was created for, and only on the bases switched on for it. AI connector tokens are refused here; they belong to /mcp.

Routes

{code} is the base code from the base's address. {table} is the table id, which is the name in the schema.

Writes must be sent with Content-Type: application/json.

Records

A record is flat. It has:

• id
• the table's fields, by their key (for example dataFieldDefault1)
• four fields the server sets: created_at, updated_at, created_by and updated_by (member ids)

{ "id": 12, "dataFieldDefault1": "Acme", "dataFieldAmount": 12000, "dataFieldStage": "proposal",
  "dataFieldTags": ["eu", "q4"], "dataFieldWon": false, "dataFieldClose": "2026-11-20",
  "created_at": "2026-11-04T10:12:00", "updated_at": null, "created_by": 7, "updated_by": null }

A link is stored by record id, so deleting a record in the linked table never moves anyone's links to another record; links to the deleted record are cleared.

GET .../schema?format=base answers with the same tables in SvGrid Base's own shape: { id, name, primaryField, columns: [{ id, field, header, fieldType, fieldProps }], views }, ready for <SvBase tables>, plus notes. The notes name everything that does not carry over exactly, such as rich text stored as HTML or a view type SvGrid Base does not have. php utilities/base-schema.php --all prints the same notes for every base on an instance.

kind names the field as Artavolo stores it, for example richText (read and written as Markdown, with format: "markdown": bold, *italic*, code, links and "- " lists; the cell keeps the HTML the old screen draws, and HTML sent by an older client is kept), collaborator (a member id), formula or ai. Fields marked readonly cannot be written: formulas and AI fields (still computed in the browser), files (use the upload flow) and created-time fields.

Each table in the schema also carries access: canCreate, canEdit and canDelete for the caller.

Reading

Rows come in record id order unless a sort is given. On an instance that encrypts cell values, filter, search and sort are refused with 400; paging still works. With format=base the schema gives each table's recordCount; the table screen reads one with more than 10,000 records a part at a time.

Airtable's API too

Scripts and tools written for Airtable's REST API can use the Airtable-compatible API at /v0/...: the same paths, ids and shapes, on top of this API. A table also exports in Airtable's CSV and JSON formats (.../tables/{id}/export?format=airtable-csv|airtable-json).

Computed fields

Formulas, lookups, rollups and counts made in the table screen are worked out on the server too, in PHP (libs/BaseCompute.class.php and libs/Formula.class.php, a port of SvGrid Base's engine that tests/formula_test.php checks value by value against it), so a read gives the values people see. Nothing has to run beside PHP. They come with each record under their field key and are listed in the schema as read-only ("computed": true, kind says which).

• Linked records come into a lookup or rollup only as the caller may see them (row rules).
• They cannot be written, and records cannot be filtered or sorted by them yet: that answers 400 with a sentence, never a result that ignores the condition.
• computed=0 leaves them out (the table screen asks this way; it works them out itself).
• "Today" and bare dates are in the server's time zone, or the viewer's with tz=.
• Should working them out fail, the records still come, without them, and the answer says "computed": false.

Refusals

Every refusal is a status and one sentence: { "error": "..." }. A 422 for a batch also lists each problem under problems.

What a write also does

These are the same things that happen when someone edits in the browser:

• It follows the base's rules for who may create, edit and delete, and the table's visibility.
• It is recorded in the audit log, with the before and after values.
• It starts the table's automations.
• It sends the base's webhooks.
• It updates the table for anyone who has it open, when live updates are switched on.