Skip to content
Form and Project Settings

Allowed origins and CORS

Configure allowed origins and CORS for Qubeforms. Connect production, staging, and localhost forms, understand wildcard domains, and troubleshoot fetch preflight.

1. Set the websites that may submit

As the form owner, open Settings → General and find Allowed origins. Enter one website origin per line, then select Save general settings. Add the origin of the website hosting your form, not the Qubeforms API endpoint. An origin is a scheme, hostname, and optional port. Leave out page paths, query strings, and fragments. The rules apply to submissions and draft requests. Each form has its own list.

https://example.com
https://www.example.com
https://forms.example.com

2. Match the actual origin

https://example.com and https://www.example.com are different origins, as are http://example.com and https://example.com. Explicit port numbers also affect exact matching. Use window.location.origin in your browser console to see the value to add. Use HTTPS for production. After saving, reopen the settings and check that the entries remain: malformed entries can be discarded. Do not enter a full page URL such as https://example.com/contact, an email address, or a comma-separated list.

3. Add local development and staging sites

Add the exact origin used by each development or staging site. Local HTTP origins are supported. localhost and 127.0.0.1 are different hostnames, and changing a development server’s port requires the corresponding entry. Serve your form through a local web server instead of opening an HTML file directly with file://. A separate test form keeps test submissions and temporary origin rules apart from your production inbox.

http://localhost:3000
http://127.0.0.1:5173
https://staging.example.com

4. Use wildcard subdomains deliberately

https://*.example.com allows HTTPS subdomains such as shop.example.com and preview.shop.example.com. It does not include the bare example.com host; add that separately when needed. Wildcards are not supported in arbitrary hostname positions or page paths. Use explicit origins if you need to restrict access to particular subdomains or ports. Add only sites you intend to accept submissions from.

https://example.com
https://*.example.com

5. Know what an empty list means

An empty list allows any origin. A list containing only * also disables origin restrictions. These settings do not pause the form. To stop accepting submissions, change Status to Paused and save. Origin rules help control browser integrations, but they are not secret authentication: a server-side client can supply its own Origin header. Keep the form’s spam controls enabled and use read keys only from trusted server code.

6. Understand CORS and preflight

CORS lets browser JavaScript read responses from a different origin. Depending on the request headers, your browser may send an OPTIONS preflight before the actual POST. Qubeforms handles that preflight on public submission and draft endpoints. A successful preflight does not mean the form accepted a submission: origin rules, availability, validation, and rate limits are checked on the actual request. No CORS library is required for the browser examples in the Help Center.

7. Send browser requests correctly

Use the public form endpoint with fetch. Set Accept: application/json when you want a JSON response. For JSON bodies set Content-Type: application/json; for FormData let the browser set the content type and multipart boundary. Supported custom headers include Idempotency-Key and X-Qubeforms-Draft-Token. Do not manually set Origin in browser JavaScript, send dashboard cookies with credentials: include, or use mode: no-cors. An opaque response from no-cors prevents your script from confirming success.

8. Call from a server or command line

When the allowlist is restricted, a server-side client must send an approved Origin. Qubeforms can also derive the origin from Referer when Origin is missing. If neither is usable, a restricted form returns HTTP 403. This curl example tests preflight without creating a submission. Replace the public key and origin with your own, and then test an actual submission separately using Your first HTML form or Adding file uploads.

curl --include --request OPTIONS \
  'https://api.qubeforms.io/v1/cf_pk_YOUR_KEY/submissions' \
  --header 'Origin: https://www.example.com' \
  --header 'Access-Control-Request-Method: POST' \
  --header 'Access-Control-Request-Headers: content-type'

9. Troubleshoot a browser error

In your browser’s Network panel, inspect both the OPTIONS request, if present, and the final POST. Compare the request’s Origin with the saved list. HTTP 403 with an origin error means that list needs attention; HTTP 404 can mean an unavailable form or incorrect endpoint. HTTP 422 and HTTP 429 are validation or limit errors, not proof of a CORS problem. Check for a wrong scheme, hostname, port, custom header, or a redirect to another host. If no API response is visible, check connectivity and the request URL. Your read API integration still needs its secret key; changing allowed origins does not grant access to stored submissions.

Keep private credentials private

Public form keys can appear in browser code. Read keys, management credentials, and webhook signing secrets must stay on the server.