What 401 means for a form submission
Form endpoints identify your form with a credential — in splitforms, an access_key sent as a hidden field. A 401 Unauthorized means the request reached the server fine, but the credential check failed. That distinction matters: your HTML, JavaScript, and network are all working. The server simply doesn't recognize (or trust) the key you presented.
Compare the neighbors: 403 = key valid, action not allowed (domain lock, plan limit); 404 = wrong URL entirely; 405 = right URL, wrong method (covered in the 405 guide).
The four causes, in frequency order
1. The key was rotated and the site still embeds the old one
You (or a teammate) regenerated the key in the dashboard. The old value — still sitting in the deployed HTML — now returns 401 for every visitor. Fix: copy the current key from the dashboard and redeploy. Next time, rotate and deploy in the same window.
2. Domain lock doesn't include the live domain
Keys can be restricted to specific domains. Created on localhost or staging.example.com? Then example.com gets rejected — often as 401/403 depending on the backend. This is also why a form can work in preview but fail live. Fix: add the production domain and its www variant to the key's allowed list.
3. The hidden field is missing or misnamed
The key must arrive as a field the endpoint expects — for splitforms, name="access_key". Common typos: access-key, api_key, key, or the field living outside the <form> element (browsers only submit inputs inside the form). A template engine that strips unknown attributes can also silently drop it.
4. Cached HTML still carries the old key
You embedded the new key — but the CDN serves the pre-fix page. View-source the live URL and check the key that's actually deployed. Purge the cache if it's stale.
Diagnose in one minute with curl
curl -i -X POST \
-d "access_key=YOUR_KEY" \
-d "email=test@example.com" \
-d "message=curl test" \
https://splitforms.com/api/submit- 200 → the key and domain rules are fine. The bug is in your page: stale cache, misnamed field, or JavaScript rewriting the payload.
- 401 → read the response body. It tells you whether the key is unknown or the origin domain isn't allowed — fix that in the dashboard, not in your HTML.
Never lose submissions to auth again
Keys in browser HTML are public by nature — that's why splitforms treats the access_key as a public identifier protected by domain locks and rate limits, while the dashboard API token (used for reading submissions) stays secret and server-side. If you call the submissions API from your own backend, send the token as an Authorization: Bearer header from server code only — never from browser JavaScript, where DevTools exposes it to every visitor. See the API reference for both flows.
FAQ
What does a 401 error from my form backend mean?
HTTP 401 means the endpoint received your submission but refused it because the credential — usually the access key in a hidden field — is missing, invalid, expired, or not authorized for the domain the submission came from. It is an authentication failure, not a form-markup bug: the request arrived intact and was deliberately rejected.
My access key is correct but I still get 401 — why?
The two most common reasons: the key is domain-locked and your live domain isn't on its allowed list (staging and localhost often work while production fails), or the key was rotated/regenerated in the dashboard and the site still embeds the old value. Re-copy the current key from the dashboard and compare it character-for-character with the one in your HTML.
How do I test my access key directly?
Bypass the browser with curl: curl -i -X POST -d "access_key=YOUR_KEY&email=t@example.com&message=test" https://splitforms.com/api/submit. A 200 means the key is valid and the problem is in your page (old cached HTML, wrong field name). A 401 means the key itself or its domain restriction is the problem — check the response body, which states which.
What's the difference between 401, 403, and 404 on a form endpoint?
401 = the credential is missing or invalid (wrong/absent key). 403 = the credential is valid but not allowed for this action or origin (domain lock, plan restriction). 404 = the URL itself is wrong (typo in the endpoint path or a retired endpoint). All three look identical to a visitor — the Network tab tells them apart.
Does rotating my form's access key break the live site?
Yes, immediately — every page still embedding the old key starts returning 401. Rotate only when you can deploy the new key in the same maintenance window, or use a backend that supports multiple active keys per form so you can overlap old and new during rollout.
Can bots cause 401s on my form?
Not directly — bots with no key get 401 by design (that's the protection working). But if your key leaks into a public repo and the provider auto-revokes or you rotate it, legitimate submissions fail too. Keep keys in HTML only if the backend treats them as public identifiers with domain locks; treat dashboard API tokens as secrets and never ship those to the browser.
Need a fresh key with domain locks configured correctly? Sign in to your splitforms dashboard — forms, keys, and allowed domains are on one screen.
Related: contact form not working, test submissions without real emails, and the endpoint documentation.