How Formerie works
A form lives in a workspace, goes live when you publish it, and turns each response into a saved submission and an email. Those few ideas explain the rest of these docs.
The pieces
- Workspace: holds your forms, members, recipients, senders, domains, and templates. Plans and limits belong to the workspace, so agencies often keep one per client. See Team and access.
- Form: the questions, their checks and conditions, and how the form looks. You can reach it by a hosted link, a script embed, or your own code.
- Draft and publish: your changes stay in a draft until you publish, so the live form doesn’t move while you work. See Publish.
- Submission: one response, saved with the version of the form that accepted it. See Reading responses.
- Delivery: the email that tells your recipients about a submission, with its own status and retries. See Recipients and senders.
Where a response goes
- A visitor fills in your form, on a hosted link, in a script embed, or in your own UI.
- Formerie checks it on the server: its origin, limits, spam checks, human verification, and every answer. A refused response isn’t stored, and the visitor sees what to fix.
- Formerie saves the response under Submissions.
- Formerie emails each recipient whose conditions match, and shows the result under Deliveries. If an email fails, the response is still safe and you can retry it.
What stays on the server
The browser sends only field values, a human-verification token when the form needs one, and safe metadata such as the page address. Recipients, sender addresses, provider names and keys, templates, delivery rules, and validation rules stay in Formerie, and they never reach the page.
Public clients can’t change these rules or get around them, and the same checks run however a response arrives. For what a page can read about a form, see the public schema.