Configure, review, and publish
Every form begins with one editable sandbox draft. Production does not exist until you publish explicitly.
The draft controls schema mode, JSON Schema, exact browser origins, redirects, and basic visitor-metadata collection. Draft writes use a server revision; a stale tab receives a conflict instead of overwriting newer work.
Flexible and strict modes
Flexible mode accepts any valid field map within the platform limits. Strict mode validates a documented JSON Schema Draft 2020-12 subset: objects, arrays, required fields, primitive types, formats, enums, length/range constraints, nested structures, and controlled additional properties.
Do not configure fields for passwords, credentials, payment-card or bank data, national identifiers, protected health information, children's data, or illegal content.
Browser origins
Enter exact origins such as https://www.example.com; paths and wildcards are not accepted. Browser requests do not send FormRoost credentials. Origin validation runs again on the submission even after a successful CORS preflight.
Publishing
Publishing validates the current draft and creates a new immutable production version. Existing submissions remain tied to the exact version that accepted them. A later rollback creates another immutable production version; it never rewrites history.
Strict mode supports a bounded JSON Schema Draft 2020-12 subset: local $ref/$defs, object properties and requirements, arrays, scalar bounds, formats and patterns, enums/constants, and standard composition keywords. Remote references, executable/custom keywords, unknown keywords, more than 500 schema nodes, or more than 20 schema levels are rejected before save or publish.
Implemented control names such as _fc_idempotency_key, _gotcha, _fc_started_at, _fc_turnstile_token, and a configured custom honeypot name cannot also be customer schema fields. FormRoost reports the collision instead of silently changing the schema.
Sandbox records are disposable and expire after 30 days on every plan.