Spam protection

Each request passes through the same checks in this order:

This is the highest-value change you can make, and it costs one hidden input. Real visitors never see it; simple bots fill every field they find.

Limits apply to the endpoint, not to accounts, so they also protect a form whose URL has been scraped. The per-form and per-IP limits are independent: a busy shared office network hits the IP limit, while a targeted flood hits the form limit.

When a legitimate user is caught by a limit, show them the Retry-After value instead of a generic failure. A short "try again in a moment" beats a form that appears broken.

Listing your production domains in the form's Integration tab means a copy of your form hosted elsewhere is rejected when it declares its own origin. This is a browser-side control, not authentication: a script outside a browser can omit the header entirely.

A rejected request is not stored, so you never have to clean it up. A submission that passes the checks but still looks wrong to you stays in the dashboard, where you can filter it, read it, and delete it deliberately.

If spam keeps arriving

Most of the time the cause is an endpoint embedded in a page with no honeypot. Add one first, then restrict the form to your domains, then consider a CAPTCHA in front of the form on your own site.

Take a little context with each submission

Sending a metadata object with the page path makes patterns visible: if every spam row says /legacy-contact, the fix is on that page.