Skip to main content
Most accounts change nothing on this screen. The defaults are the recommended settings. Read it once so you recognize the behavior when a submission comes back refused. Where: Form Processing in your account settings.
You edit allowed origins on Web Edge Sessions, but they are stored with these settings. That is why their change history shows up here.
The Form Processing settings, with the submission limit, the anti-abuse controls and the response contract

The Form Processing settings, with the submission limit, the anti-abuse controls and the response contract.

​
Max payload size

Shown as a read-only value, 8 KB by default. That’s generous for a lead form; if you’re near it, you’re probably sending something that shouldn’t be in a form submission. A larger limit is available through support. It’s measured in bytes, not characters, so accented and non-Latin text counts for more than its length suggests. An oversized submission is refused as validation.

​
The checks, and the order they run in

The anti-abuse checks run in a fixed order and stop at the first failure. That means the code you get back names the first thing that was wrong, not everything that was wrong. Exactly one code describes any submission.

​
Rate limiting

On by default. Two separate budgets: Tracking events have their own separate budgets, so a flood of tracking can’t use up the allowance real submissions depend on. Going over returns rate_limited, and the script shows the visitor “Too many attempts. Please wait a moment and try again.”
Load-testing a form from one machine trips the per-IP budget after 30 submissions in a minute. That’s correct behaviour, not a bug.

​
Honeypot field detection

On by default, using the field name _hp. A honeypot is a hidden field a human never sees and never fills. Bots that complete every input fill it, and the submission is refused. Only a non-blank value counts. Browsers submit empty strings for untouched inputs, and rejecting those would reject everyone. The allGood script adds the field for you and keeps it empty. Don’t add your own, don’t style it visible, and don’t let your own code write to it. A form can name its own honeypot field, which overrides the account default; switching the check off account-wide beats both. The honeypot value is kept in the stored record as evidence about the submission. The bot-check token is different: allGood discards it once it is verified.

​
Bot protection

Bot protection (Turnstile) or None. See Turn on bot protection for a form. The account setting and the form’s own opt-in must both be on for a check to run. This is described in the app as the only control that reaches a caller which isn’t a browser, and that’s accurate: a non-browser caller has no website to check and no honeypot worth trusting.

​
The response contract

The bottom of the screen lists the codes a submission can come back with. They are read-only. It is a reference, not a setting.
The response contract, listing every code a submission can come back with

The response contract, listing every code a submission can come back with.

Full detail, including what your page should do with each: Reason codes. Two things that table is telling you:
  • A form submission is never refused for missing consent. That’s deliberate.
  • Exactly one code describes a submission, because the checks stop at the first failure.

​
Saving

One Save button covers the whole screen, in the bar at the top next to the status chip. Save writes to allGood; the chip tells you when the change is actually in force. See Saved vs live.