Guides

Form capture & spam protection

Every form a CurateOne site renders — contact, booking, RSVP, survey — posts to two public capture endpoints. Here's the contract, the spam defenses in front of your inbox, and where the data flows next.

How capture works

Published sites resolve their project by the request's Host header, so the same static markup works on your .curateone.ai subdomain, a custom domain, or a downloaded export — no keys, no per-site configuration. Contact-style forms post to POST /api/site/leads; widget forms (booking, RSVP, survey, applications…) post to POST /api/site/submissions.

POST /api/site/submissions — body

{
  "type": "booking",            // booking | rsvp | survey | feedback | application |
                                // order | registration | webinar | meeting | newsletter | multistep
  "name": "Asha Patel",
  "email": "asha@example.com",  // at least one contact point or one field is required
  "phone": "+91 98765 43210",
  "message": "Table for four on Friday.",
  "fields": { "Guests": "4", "Time": "19:30" },
  "path": "/reservations",
  "elapsedMs": 5321,            // time from render to submit (spam signal)
  "company_website": "",        // honeypot — must stay empty
  "recaptchaToken": "…"         // present when the reCAPTCHA widget is enabled
}

Leads take the same shape minus type (with name and email required). Both endpoints are IP rate-limited and reply with a generic success envelope.

Spam defenses, in order

Honeypot + timing — a hidden company_website field that must stay empty, and an elapsedMs floor; failures are dropped silently so bots can't learn.
IP rate limits— per-endpoint buckets shared across a project's capture surface.
reCAPTCHA v3 (optional)— when the site has the Google reCAPTCHA widget enabled and its secret on file, every submission's token is verified server-side with Google; missing tokens and scores below 0.3 are rejected with a generic 400.

reCAPTCHA fails open: if Google's verification service is unreachable, the submission goes through on the built-in defenses alone — an upstream outage can never cost real leads.

Where the data goes

Stored in the project's Leads / Submissionsinbox (the Studio's ⋯ menu).
Emailed to the owner's account address — and, when the form widget has a notification email configured, to that address too (bookings to the front desk, applications to hiring).
Fired as automation events — lead.created and form.submitted — which can push HMAC-signed webhooks to your systems.
Readable over the v1 API: GET /api/v1/sites/{id}/leads.