429 Rate Limit Error: Why Your Form Submission Failed

Your form worked fine in testing. Now a real visitor fills it out, hits submit, and gets nothing back but an error. You check the response and it says 429. The submission never arrives in your inbox or your dashboard, and you are left guessing whether your form is broken or something else stopped it.

A 429 rate limit error is SimpleForm's way of saying too many submissions came from the same IP address to the same form endpoint in a short window. It is a spam control, not a bug, and it is separate from the monthly plan limit that returns a 402 instead. Knowing which one you are looking at changes what you do next.

The scenario this hits most often is not an attack. It is a launch day, or a demo, where you or a teammate submit the same test form five or six times in a row while checking that emails arrive, then a real visitor's submission a few minutes later gets the 429 instead of yours getting flagged.

What Triggers a 429 Rate Limit Error?

SimpleForm caps each IP address at 10 submissions per endpoint per hour. Once a single visitor or script crosses that ceiling on one form, every further POST to that endpoint from that IP returns HTTP 429 until the hour window rolls over.

This sits in the middle of SimpleForm's three spam-defense layers, applied in a fixed order: honeypot detection runs first, IP rate limiting second, and optional reCAPTCHA v3 last on Pro and Agency plans. A submission that trips the honeypot field still returns HTTP 200, so a bot never learns it was caught — but a submission that trips the rate limit gets an honest 429, because at that point the sender is not being deceived, just slowed down.

The count is scoped narrowly, to one IP address against one endpoint token. Ten submissions to your contact form and ten submissions to your newsletter signup form from the same visitor are tracked separately, since each form has its own token in the action URL, and neither total affects your account-wide monthly quota.

Why Do AJAX Forms Hit This More Often Than Standard Ones?

A standard HTML form post is naturally rate-limited by how fast a human can click submit and wait for the page to reload. An AJAX form, submitted with the fetch API and an Accept: application/json header, has no such pause built in — a bug in the JavaScript can fire the same POST request in a loop far faster than any person would click.

The usual culprits are a submit handler attached twice, once from an inline script and once from a bundled one, a retry-on-error branch with no delay or attempt cap, or a loading state that does not actually disable the button, letting an impatient visitor click three or four more times while waiting. Each of those turns one intended submission into several counted ones, and a handful of visitors doing it independently is enough to reach the ten-per-hour ceiling on a form that otherwise gets light traffic.

How Is a 429 Different From a 402 Submission Limit Error?

A 429 and a 402 look similar in a network log but mean opposite things. A 429 is about the rate of requests from one IP to one endpoint, measured in an hour. A 402 is about your account's total submissions for the whole month, measured against your plan.

That distinction matters because the fix is different. A 429 usually clears itself within the hour and often points to a bug on your form. A 402 does not clear until next month unless you upgrade your plan, since the Free plan includes 100 submissions a month, Pro includes 5,000, and Agency includes 25,000. The table below lists every response code SimpleForm's submission endpoint can return, so you can tell at a glance which bucket you are in.

How Do You Diagnose Which Requests Are Getting Throttled?

Before you change anything, confirm the 429 is coming from real traffic and not a mistake in your own code. Work through these checks in order.

1. Open your browser's network tab and confirm the response status is genuinely 429, not a generic fetch failure being misread as one.
2. Check your dashboard's submission log for the endpoint and look for a burst of entries from the same IP within a single hour.
3. Look for a duplicate submit-event listener on the form, which fires two or three POST requests per click instead of one.
4. Check any client-side retry logic for a loop that resubmits on failure without a backoff delay.
5. Count how many times you personally have test-submitted that same form today — repeatedly submitting your own form while developing is the single most common cause of a self-inflicted 429.

How Do You Fix or Prevent 429 Errors on Your Form?

Most 429s trace back to a form that submits more than once per click. Disable the submit button the instant the click handler fires, add a debounce around the submit event, and make sure any AJAX retry only fires after a confirmed network failure, with a short delay, rather than on every response your code does not immediately recognize as success.

If the traffic is genuinely 10 or more legitimate submissions from one visitor's IP inside an hour — a shared office network filling out the same lead form, for instance — that is a rarer case worth checking against your endpoint's request log in the dashboard rather than assuming it is abuse. Building and tuning your own IP-based throttle by hand, deciding on a window, a ceiling, and a storage layer for the counters, is exactly the kind of infrastructure SimpleForm exists to remove; the limiter, the honeypot, and the response codes above are already active on every form the moment you create one, and the full configuration options are covered in the documentation.

What About Forms With Legitimate High-Volume Traffic?

The most common objection here is that a fixed 10-per-hour ceiling sounds too low for a busy contact page or a popular signup form. In practice, the limit is per IP address, not per form overall, so it only affects one visitor hammering the same endpoint — a normal launch-day traffic spike from many different visitors never touches it, because each visitor's ten-submission allowance is separate. If your form legitimately needs a different threshold, for example an internal tool submitted from behind one shared corporate IP, that is a configuration conversation worth having directly with support rather than working around with retries, since retries against an active rate limit only extend how long the block lasts.

What Should You Do Next?

If you are debugging a 429 on a form you already run, fix the double-submit or retry-loop bug first — that resolves the large majority of cases without touching any settings, and the error stops recurring on its own once the hour window passes. If you are still deciding how to handle spam and abuse on a static site's forms without writing that logic yourself, create a free SimpleForm account and send a real test submission to a new endpoint; the honeypot and rate limiter are active on it immediately, with no configuration required before your first form goes live.

Frequently asked questions