Rate limiting

Rate limiting caps how many requests a client may make within a time window - say, a handful of submissions per minute from one IP address. Requests beyond the cap are refused, conventionally with HTTP status 429 (Too Many Requests), until the window resets.

For anything that accepts public input, rate limiting is the first structural defense. It does not judge whether a request is good or bad; it judges volume. A human filling out a contact form generates a submission every few minutes at most. A script hammering the same endpoint generates hundreds per second. A per-client cap makes the second case impossible while the first case never notices the limit exists.

Limits are usually layered by key. A per-IP limit stops a single machine from flooding; a per-resource limit (per form, per API key) caps total damage even when an attack is spread across many IPs. The craft is in the thresholds - tight enough to blunt abuse, loose enough that a legitimate burst, like a form embedded on a suddenly popular page, sails through.

SheetLink Forms applies rate limits per form and per IP on every endpoint. Requests over the limit receive a 429, and the caps are tuned so real traffic - even a busy launch day - does not brush against them. Rate limiting sits alongside the rest of the layered spam stack: the _slhp honeypot, the per-form origin allowlist, content heuristics with a strictness dial, the sl.js timing signal, and optional Cloudflare Turnstile. Suspicious-but-plausible submissions go to quarantine for review rather than being dropped.

The full stack is described on the security page, with response codes listed in the docs.