Point any HTML form at one endpoint. 500 free submissions — no card, no time limit — and unlimited forms.
Create free accountWhich key belongs in a public form?
A working browser form must reveal its destination. Moving an access_key from a hidden input into JavaScript, or putting it in a frontend environment variable, does not make it secret. Visitors can inspect the generated page and its network requests. That is expected for a submission-only form endpoint.
The important question is what the credential permits. A public form key selects where an incoming message goes. An account token may authorize reading records or managing resources. Copy the form key from the form’s setup screen, and use the documented authentication mechanism for any separate account integration.
| Credential | Public frontend? | Intended use |
|---|---|---|
| Form access key | Yes | Route submissions to the intended SplitForms form. |
| Account API token | No | Authenticated operations permitted by the token. |
| MCP bearer token | No | Connect an authorized AI client to account tools. |
| Webhook signing secret | No | Verify incoming delivery signatures on your server. |
| CAPTCHA site key | Yes | Initialize a browser verification widget. |
| CAPTCHA secret key | No | Server-side verification, configured with the backend. |
References: SplitForms API reference · SplitForms MCP authentication
Why hiding a key or enabling CORS is not enough
CORS controls whether browser JavaScript can read a cross-origin response. It does not stop arbitrary HTTP clients from sending requests. A script running outside a browser can send requests directly, so a public key plus an origin policy is not the same as authenticating a trusted sender.
Allowed Domains is useful for catching unintended deployments and restricting the browser sites that use a form. Combine it with server-side abuse controls. Do not treat a Referer or Origin header as proof of a visitor’s identity, and do not fix a CORS error by switching fetch to no-cors: you would lose access to the response details your success UI needs.
References: MDN: CORS · SplitForms origin and submission errors
A practical protection checklist for SplitForms
Start with one form per workflow so you can inspect submissions and settings separately. Keep the honeypot empty for legitimate visitors, preserve any timing field generated by the integration, and configure the real production hostname before enabling strict origin protection. Check both the root domain and the www hostname you actually use.
For persistent abuse, enable a supported verification provider and complete both browser and server configuration. A widget rendered on the page is only half the integration. Review spam outcomes after a change so a stricter rule does not quietly reject your genuine customers.
- Use the public form key, never an account or MCP token, in the submitted request.
- Keep recipient addresses and integration credentials in the dashboard settings.
- Use honeypot, rate limiting and spam filtering together; no individual signal catches every bot.
- Check the dashboard and Spam view during a controlled test.
- Keep logs useful without copying full visitor messages or secrets into analytics.
References: SplitForms spam controls · SplitForms security
What to do when a key appears in a repository
First identify the credential. Finding the intended form access key in frontend source is different from discovering a privileged token. If a management credential was exposed, revoke or rotate it through the relevant account controls, update the service that uses it and review the actions it could authorize. Deleting a line from the latest commit does not remove older copies.
If a public form key is attracting spam, inspect the affected form and strengthen its controls. Changing the key without fixing an exposed privileged token would address the wrong problem. Equally, building a proxy solely to hide a submission endpoint adds maintenance without making the public contact form private.
References: Authentication and form setup
Where a hosted form backend helps
SplitForms is useful when you want a public website form without maintaining a custom email route, database and spam pipeline. The dashboard gives you a place to inspect accepted submissions before investigating email delivery, and a separate authenticated API or MCP connection can support authorized operations.
Choose a custom authenticated workflow when the submission represents a privileged action, such as changing an account or approving a payment. A public contact-form endpoint is intended to collect messages. Keep authorization for business actions in the application that owns those actions.
References: SplitForms API reference · Submission lifecycle
Frequently asked questions
Can someone read my submissions with the public form key?
The public submission key routes incoming form requests. Reading private records uses separate authenticated account access; do not substitute an account or MCP token into a public form.
Does a frontend environment variable hide the key?
No. Values included in browser code or requests can be inspected. Only put credentials designed for public use in the frontend.
Is a hidden input secure storage?
No. Hidden means it is not displayed as a normal control. The value remains visible in page source and the network request.