Brent Haskins / Applied AI
Rate limits on public form endpoints are part of UX
As of May 2026, public form POST endpoints without rate limits invite spam and credential-stuffing adjacent abuse. Brent Haskins pairs limits with honeypots and validation (see the public form spam post on this blog) so legitimate campaigns keep working while bots hit a visible wall.
Spam posts are the loud problem. Rate limits are the silent insurance policy.
User-visible failure
When limited, return a clear message:
“Too many submissions from this network. Try again in a few minutes.”
Silent drops feel like your product lost data.
Owner dashboard
Show:
- Accepted vs throttled (last 24h)
- Top IPs (hashed if you store them)
- Webhook success rate
Ops users forgive limits they can see.
Webhook protection
Throttle saves Zapier partners from duplicate storms.
AI feature endpoints
Generation endpoints need stricter per-account limits than public embeds—cost control plus abuse.
Author
Brent Haskins — /projects/formably. Limits are product behavior, not only infra tickets.
FAQ
Questions people ask about this topic.
Why rate limit public form submission endpoints?
Unlimited POST endpoints are cheap attack targets for spam, resource exhaustion, and downstream webhook noise. Rate limits per IP and per form ID protect deliverability and database costs. Return 429 with Retry-After when possible; log blocked attempts for owners reviewing campaign abuse.
What rate limit strategy works for SaaS form builders?
Use layered limits: generous burst for humans filling one form, tighter limits per IP per hour, and separate caps on webhooks fired. Whitelist office IPs optionally. Show owners a graph of blocked vs accepted submissions. Combine with honeypots and server-side validation—not CAPTCHA unless abuse persists.
Sources