Form submissions — capture, route, and respond

Every form on a Builder site (contact forms, quote requests, RSVP forms, custom-built forms) writes a submission to Firestore that you can read, route into your CRM, and respond to from one place.

To add a form to a page:
1. Builder → open page → drag in a Form block (or use the "Contact Form" block for a pre-built version)
2. Configure fields (text, email, phone, dropdown, file upload, multi-line)
3. Set the destination — submissions are stored on the org by default; optionally also POST to a webhook URL for external CRMs
4. Set the auto-reply — visitor sees "Thanks!" and gets an email confirmation if they provided one

Where submissions live:
• Builder → Sites → your site → Submissions tab
• Each row shows: who submitted, when, which form/page, full payload, status
• Statuses: New / Reviewed / Replied / Archived
• Filter by site, form, date range, status

Auto-reply templates:
• Pick from your Email Templates library, or write a one-off
• Variables available: {{firstName}}, {{formField:fieldId}}, {{orgName}}, {{currentDate}}
• Sends from your verified sending domain via Resend
• Subscribed to the same suppression list as Email Campaigns (so opt-outs are respected)

Routing into CRM:
• Toggle "Auto-create Contact" on the form — every submission creates a Contact in your CRM with the form data
• Optional: tag the new contact based on which form ("newsletter-signup", "demo-request", "support")
• Optional: create an Opportunity for sales-flow forms — pre-stamped with the form's source so reps know the channel
• If contact already exists by email, the submission is appended to their record (notes section) rather than duplicating

Webhook delivery:
• Set "Webhook URL" on the form to POST every submission as JSON to your external system
• Failed deliveries retry with exponential backoff for 24 hours
• Audit log shows delivery status per submission
• Webhook payload includes a signature (HMAC) header so your endpoint can verify the request came from Turtini

Spam protection:
• Captcha (Cloudflare Turnstile) is ON by default on every new form. You can turn it off per form under Spam protection.
• The captcha needs a Turnstile widget on your own Cloudflare account. Connect Cloudflare under Integrations and the widget is created for your domains, so the challenge runs under your account and stays yours.
• Until that widget exists, no visitor is challenged — and the form says so. The Spam protection panel tells you the captcha is not running and why, and every lead is badged Unverified in the Lead Inbox. The setting never claims a protection you are not getting.
• A hidden honeypot field runs on every submission whether or not the captcha does, and it is checked on our servers rather than in the visitor's browser.
• A submission that trips the honeypot, or whose challenge Cloudflare rejects, is flagged and lands in the Spam view of the Lead Inbox — you can still read it. Nothing is silently discarded.
• What a captcha does, stated plainly: it raises the cost of submitting your form automatically through the page. It is not a rate limit, and it does not cover a program posting straight to the submission endpoint.
• A site exported to GitHub is plain HTML with no scripts, so no challenge appears on the exported copy. Its honeypot still works, and its submissions are recorded as unverified.