A contact form that worked last week and now throws a blank error page costs you leads before you even know it's broken. If your static site's form submissions have started failing with a 404 response, visitors are typing their name, email, and message into a form that silently refuses to accept it. No error message reaches them, no email reaches you, and the first sign of trouble is usually a customer asking why nobody replied.
SimpleForm is a hosted form backend for static websites: you point your HTML form's action attribute at a SimpleForm endpoint URL, and it emails you the submission and stores it in your dashboard. A 404 response from that endpoint means the token in the URL doesn't match any active form on your account — the request reached SimpleForm, but SimpleForm has nothing to hand it to.
What does a 404 error actually mean here?
Every SimpleForm endpoint follows the pattern https://simpleform.dev/f/{token}, where the token is a unique string generated when you create a form in your dashboard, something like abc123xyz. According to SimpleForm's own response code reference, a 404 specifically means the endpoint token was not found or the form behind it is inactive. That's different from a form that exists but rejected the request for another reason — a 404 means SimpleForm never matched the token to a form at all.
This matters because a 404 is not a spam-protection response and not a plan-limit response. It's a routing failure. The fix lives in the token and the form record, not in your rate limits or your recipient list.
Why did my form endpoint stop working overnight?
Three things produce this exact failure, and all three are common enough that none of them mean something is wrong with SimpleForm itself.
The most frequent cause is a copy-paste error. Someone retypes the token by hand instead of copying it, or copies it from an old commit, an email, or a teammate's Slack message that had the wrong form pasted in. A single dropped or transposed character in the token produces a 404, because SimpleForm matches the token exactly — there's no fuzzy matching or "did you mean" fallback.
The second cause is deploying a static site build that still has last quarter's token baked into a template, while the dashboard now points a different token at the live form. Static site generators cache aggressively; if the form partial lives in a shared layout file, an old build artifact can serve a stale action URL long after the source file was corrected.
The third cause is the form itself. If a form was deactivated or removed from the dashboard — deliberately, during a cleanup, or by a teammate who didn't realize a live site still pointed at it — its token stops resolving and every request against it returns 404 from that point forward.
How do you find the correct endpoint token?
Sign in to your dashboard at /login.php and open the form the page is supposed to submit to. The endpoint URL shown there is the source of truth — copy it directly rather than retyping any part of it, including the https:// prefix and the exact token casing. Then compare it character by character against the action attribute in your HTML.
If you're not sure which form on your account is meant to receive a given page's submissions, especially on an account with several forms, check each form's configured redirect URL and allowed domains in the dashboard — the one matching your site's domain and thank-you page is the one you want.
How is a 404 different from a 403 or a 429 error?
These three response codes get confused because they all mean "your submission didn't go through," but each one points at a completely different fix. Mixing them up wastes time chasing the wrong cause.
| Code | Meaning | Where to look |
|---|---|---|
| 400 | Missing or invalid form data | Required field names and values in your HTML |
| 403 | Request came from a domain not on the form's allowed-domains list | Allowed domains setting in the dashboard |
| 404 | Endpoint token not found or the form is inactive | The token in your form's action attribute |
| 429 | More than 10 submissions from the same IP to the same endpoint in an hour | Rate limiting — usually a testing artifact, not a real problem |
A 403 tells you the token is fine but the domain is blocked. A 404 tells you the token itself is the problem. If you've been staring at your allowed-domains list trying to fix a 404, that's the wrong setting — go back to the token.
How do you fix a 404 endpoint error?
Work through these in order; the fix is almost always found in the first two steps.
- Open the form in your SimpleForm dashboard and copy its endpoint URL directly, rather than retyping any part of it.
- Paste that URL into your HTML form's
actionattribute, replacing the old value entirely. - Check your static site build output (not just the source file) to confirm the deployed HTML contains the new URL — a stale cached build is a common culprit.
- Confirm the form is listed as active in the dashboard, not archived or deleted.
- Test with a real submission and check both your inbox and the dashboard's submissions list for the new entry.
- If it still 404s, use a terminal to send a direct request to the endpoint and read the response, which removes your browser and any JavaScript from the equation.
Once the token and the deployed HTML agree, the endpoint resolves immediately — there's no propagation delay or caching layer on SimpleForm's side to wait out.
It also helps to rule out the browser cache while you're testing. A hard refresh, or an incognito window, confirms you're looking at the page your visitors actually load rather than a locally cached copy of the old form markup. This step alone resolves a surprising share of "I fixed it and it's still broken" reports, because the fix was real but the tab checking it wasn't.
How do you stop this from happening again?
Once the immediate 404 is fixed, a few habits keep the next deploy from reintroducing it. Store the endpoint token in one place, such as a shared template partial or a build-time variable, rather than pasting the full URL into every page that has a form, so a token change only needs to happen once. Before archiving or deleting a form in the dashboard, search your site's source for its token to confirm nothing live still points at it. And after any deploy that touches a form, submit a real test entry and check for it in the dashboard, the same way you would smoke-test any other page after a release.
Should you just build your own form-handling backend instead?
If a token mismatch can take your contact form down, it's fair to ask whether a small server script you control would be more reliable. In practice the opposite tends to be true: a hand-rolled endpoint fails the same way — a wrong URL, a misconfigured route — except now you're also the one maintaining the mail sending, the spam filtering, and the uptime, instead of pointing a single HTML attribute at a URL you can verify in one command. The fix for a 404 here takes under a minute, precisely because there's nothing else to run or patch.
The full response code reference, the form configuration options, and the AJAX submission pattern are documented at /docs/ if you want to see how the rest of the request lifecycle behaves before you troubleshoot further.
What should you do next?
If you're chasing a 404 on a form you haven't set up yet, or you're comparing SimpleForm against writing this yourself, create a free account and generate a real endpoint token — it takes about a minute, and you can send it a test submission immediately to see the token-to-form match in action. Start free at /register.php.
Frequently asked questions
It means the token in your form's action URL doesn't match any active form on your account. SimpleForm received the request but found no form record for that specific token, so it returned 404 instead of accepting the submission. This is distinct from a 403, which means the token matched but the sending domain was blocked.
This usually means your live site's deployed HTML still has an old or mistyped token in the form's action attribute, even though the token you're testing with locally is correct. Static site builds can cache an old template. Check the actual deployed page source, not just your local source file, to confirm which token is live.
No. A token only stops resolving if the form it belongs to is deactivated or removed from the dashboard, or if the token was never valid to begin with, such as a copy-paste error. There's no automatic expiration tied to time or inactivity that would silently break a working endpoint.
A 403 means the token is valid but the request came from a domain not on that form's allowed-domains list, so check the domain restriction setting. A 404 means the token itself doesn't match any form at all, so the fix is in the endpoint URL, not the domain settings. Confusing the two wastes time fixing the wrong setting.
Send a direct request to the endpoint from a terminal rather than your browser, which lets you read the raw HTTP response code without any JavaScript or redirect masking it. A 404 response confirms the token problem independent of your site's code. Once you see a 200 or 302 instead, the token is resolving correctly.
No. A 404 means the request never reached a valid form, so nothing is stored, emailed, or counted. Submission limits only apply to requests that successfully match an active endpoint token; a routing failure like a 404 doesn't touch your usage at all.