Forms and leads

Atlas forms collect enquiries on your website and turn each one into a lead that your team can assign, follow up and export. Forms work on your Development website and, once Production is live, on your live website.

How it works

1. Build the form in Studio. Fields, labels, consent text, submit label and success message, under Forms & leads.

2. Your website renders it. It fetches the form definition and draws the fields with its own components, so the form matches your design.

3. The visitor submits. The browser posts directly to Atlas. No token is involved: Atlas only accepts requests whose Origin is your website’s registered address.

4. Atlas checks and stores it. Spam and abuse checks run first, then the lead is saved, emailed to your team and sent to your webhooks.

Development and the live website

	Development website	Live website (Production)
When forms answer	Always	When Production is turned on and a signed release is live
Which form version	The latest published draft	The version inside the live release
Accepted origin	Your Development addresses	Only https:// your Production domain
Where leads appear	Leads → Development	Leads → Live website (“Leads from the live website”)
Lead emails	Off by default	On by default; can be paused

Forms travel to Production inside releases, just like pages. A form you change in Development reaches the live website with the next approved release, and a form removed from a release stops answering there.

While Production is off, its form addresses answer 404 CP_NOT_FOUND. If Production is on but no signed release is live yet, they answer 403 CP_PRODUCTION_LOCKED.

Render the form

// GET /v1/public/environments/{environmentId}/forms/{formKey}
// → { key, name, version, fields, settings: { submitLabel, successMessage, consentText },
//     challenge: { provider: 'turnstile', action, siteKey } }

Render the fields with your own inputs. If challenge.provider is turnstile, render the Cloudflare Turnstile widget with the given siteKey and action, and allow Turnstile in your Content-Security-Policy.

Submit

// POST /v1/public/environments/{environmentId}/forms/{formKey}/submissions
{
  "idempotencyKey": "<new UUID per attempt>",
  "sessionId": "<16–128 chars, A–Z a–z 0–9 _ ->",
  "startedAt": 1761210000000,       // when the visitor opened the form, in ms
  "challengeToken": "<Turnstile token>",
  "website": "",                    // hidden honeypot field; leave empty
  "consent": true,
  "fields": { "name": "…", "email": "…", "message": "…" }
}

Response	Meaning
201 { status: 'received' }	Accepted. Show settings.successMessage
422 SUBMISSION_INVALID	A field failed validation. Show the field errors
400 SUBMISSION_REJECTED	Rejected, for example a failed challenge
429	Too many submissions. Ask the visitor to try again later

Suspicious submissions are quarantined but still get a 201, so attackers cannot learn what was flagged.

Spam and abuse protection

• Cloudflare Turnstile challenge, per site.
• Honeypot field and minimum fill time.
• Duplicate detection within 10 minutes.
• Rate limits per site, form, visitor session and IP address. See Limits.

The Spam review tab in Studio shows quarantined submissions from Development. Quarantined submissions from the live website cannot be reviewed in Studio yet.

Lead emails

The site owner adds an email connection (SMTP or an email provider) under Integrations → Email. Passwords and API keys are stored encrypted and are never shown again or logged.

The card Email for enquiries and leads has two switches:

• Live website: on by default once Production is live. Turn it to “emails paused” to stop emails without touching the forms.
• Development: off by default, so test submissions do not email anyone. Test submissions are marked [Test].

Only a site admin can change these switches. Automatic replies to visitors are off unless you turn them on.

What to read next

Work with leadsAssign, merge, export and clean up leads, and send them to your CRM.Go livePublish a release and turn on Production so forms answer real visitors.