Allow browser origins with CORS

CORS Origin controls which websites can make browser requests to your sandbox and production gateway APIs. It is configured separately from country and IP validation.

Configure an environment#

Open Workflows → CORS Origin. Sandbox and production each have an enable switch, an allowed-origin list, and a browser-credentials option.

1. Enable the environment you want to restrict.
2. Add the exact browser origin for each app.
3. Enable browser credentials only if the integration needs them.
4. Select Save changes.

https://app.example.com
http://localhost:5173

An origin contains the scheme, hostname, and optional port. Do not include a page path, query, fragment, username, wildcard, or the literal value null. Different subdomains, schemes, and non-default ports need separate entries.

Built-in Cloudgate origins#

cloudgate.dev and its subdomains are allowed automatically. They do not need to be added to the list. With validation enabled and an empty list, only those built-in origins are allowed. Each environment accepts up to 100 additional origins.

Disabling an environment preserves its saved origins and credentials setting. Its browser-origin restriction no longer applies until enabled again.

What happens to a request#

An allowed preflight returns 204 without running the workflow. An origin outside the enabled allowlist is rejected with 403 before execution, including simple browser requests that have no preflight.

Use the tenant's API hostname. Preflights do not carry API-key or login credentials, so the hostname must identify the tenant.

Requests without an Origin header continue through the existing API controls. CORS is a browser policy and does not replace gateway authentication or user authorization.

Debug in the browser#

Inspect both OPTIONS and the actual request. Confirm the exact origin, selected environment, API hostname, and response status. A permitted origin can still receive an authentication error; fix that access layer rather than adding more origins.