Fillo uses a small set of objects to keep rendering, validation, collection, and review aligned. Here's what each one means.

Form

A form is one named collection flow with a draft, an optional published version, settings, destinations, and responses. A published form has a public ID and slug that SDKs or hosted pages can load.

Dashboard-managed and code-defined forms use the same stored form model. A code form also has a stable developer handle, such as customer-onboarding, used during sync.

A field is a question that stores its answer under a stable ID. The kind selects the value shape and validation behavior. Labels can change; IDs shouldn't, because they connect responses, conditions, exports, and integrations across versions.

Headings, paragraphs, and dividers are content blocks. They shape the layout but don't store answers.

Schema

A schema is the versioned JSON definition shared by the editor, renderers, client and server validation, response display, and destinations. It contains pages, blocks, and settings. defineForm and Fillo JSX compile to this same schema.

Response

A response is one completed submission. Fillo stores its answers, source and timing context, respondent association where present, file references, delivery state, and the form version it answered.

Saved progress is a draft, not a response. It doesn't count as a completed response, and it appears separately when the owner enables in-progress answer visibility.

Respondent

A respondent is the person identity associated with one or more responses or drafts in a project. An embed can claim an app user ID, email, and name. The identity becomes verified only when your server signs the stable ID with the project identity secret.

Anonymous browser state, a typed email answer, and a server-verified signed-in account carry different trust levels. Pick response limits and submission policy accordingly.

Workspace

A workspace is the billing, membership, and shared-connection boundary. It owns members, the subscription and aggregate limits, storage connections, and reusable integration accounts.

Project

A project is an isolated site or app inside a workspace. It owns forms, responses, respondents, publishable keys, API and CLI credentials, allowed origins, identity secrets, code-sync policy, and agent or MCP authority. Management reads and writes target one selected project.

Projects share the workspace's bill, members, storage, and reusable integration accounts. A response integration must still be attached to a project, and each form pins the exact connected account it uses.

Version

A version is the published schema snapshot a respondent saw. Editing creates a draft; publishing makes that snapshot live. Each response keeps its version reference, so later edits don't silently rewrite which structure accepted the answer.

How the objects connect

A workspace owns one or more projects.
A project owns a form and its credentials.
The form publishes a schema version.
A renderer loads that version and collects field answers.
Submission creates a project-scoped response, optionally attached to a respondent.
Fillo sends the stored response to the form's pinned destinations.

Schema and validation: Inspect the canonical structure and validation rules.
Respondents and identity: Choose between anonymous, claimed, and verified identity.
Responses and insights: Work with completed submissions and their versions.
Workspaces and projects: See what is isolated and what is shared.

Core concepts