Projects and surveys

The data model is intentionally small. Everything hangs off three tables:

User

Internal admin user. There is no public sign-up — users are created by seed or by an administrator running the seed script. Each user owns one or more projects.

Project

A workspace that scopes:

• A list of surveys
• A set of API keys (used by your backend to script template creation)

Projects have a unique slug so that you can reference them from your own systems without exposing internal IDs.

Survey

A survey lives inside a project. It has:

• A unique slug (used in the public URL)
• A list of questions (see Questions)
• An optional theme (logo, brand name, primary colour)
• An optional metadataSchema describing the metadata keys you will attach to each response template
• A status: DRAFT, PUBLISHED or ARCHIVED

Response and ResponseTemplate

The platform does not expose anonymous public submissions. Every response goes through a ResponseTemplate:

1. The admin (or your backend, via API key) creates a ResponseTemplate for a given survey, attaching whatever metadata they want (recipient email, purchase ID, store, language, etc.).
2. The system returns a token and a url of the form /r/{token}.
3. The recipient opens the URL, fills in the answers and submits.
4. The token is now consumed — but the recipient can edit their response while the survey remains published.

This design gives you:

• One link per recipient (no shared anonymous URL)
• Metadata travelling with each response without ever being shown to the respondent
• Editable responses without authentication

See Response templates for the full flow.