Skip to main content
Forms are authored in the Builder by adding a Form block to a page and binding its fields to a schema-defined table. This resource gives you read access to the form definitions and their submissions. Form creation is Builder-only — there are no write endpoints for form schemas. Submissions are written by end-users filling out the rendered form on your live page, not through this API. By the end of this page you will know what reads exist, how submissions are paginated, and what the on-submit hook represents.

A submission in shape

data keys mirror the field names on the form definition; values are the end-user input.

Endpoints

List all forms in the workspace. Fetch the schema for a specific form. Paginated submission records for a form. All three endpoints require forms:read. There are no write endpoints — forms must be created and edited in the Builder.

What a form definition carries

The on_submit hook lets a form trigger a workspace capability — typically sendEmail for confirmation — without separate wiring.

Submissions pagination

GET /forms/{id}/submissions returns submissions newest-first, with cursor pagination. Defaults: limit=50, maximum 200. Cursor mechanics match the Pagination protocol; the response shape is the standard data + next_cursor envelope, with an extra boolean has_more.

Limits

Common errors

Form block

Add a Form block, bind it to a schema table, and wire an on-submit capability in the Builder.