Troubleshooting: Browser Events Get 403 / "Origin not allowed"

This happens when a browser request's Origin header doesn't match any domain verified for the workspace. Server-to-server requests are unaffected - they don't send an Origin header, so this only applies to requests made directly from a page (the JavaScript SDK, or a manual fetch/XHR call).

How Origin Matching Works

For every browser request, the API checks the Origin header against the workspace's list of verified domains (AllowedOrigins, built from verified rows in workspace_domains). An origin is allowed if any of the following match:

1. Exact match - the origin's host is identical to a verified domain (https://axi.yourdomain.com matches a verified axi.yourdomain.com).
2. Same registrable domain (eTLD+1) - added 2026-08-05 - the origin and the verified domain share the same registrable domain per the Public Suffix List. This means verifying axi.shop.com also admits the apex (https://shop.com) and any sibling subdomain on the same registrable domain, such as https://www.shop.com or https://checkout.shop.com - even though neither of those was individually verified. This does not cross registrable-domain boundaries: verifying axi.shop.com.pl does not admit https://other.com.pl, because eTLD+1 for a multi-part public suffix like com.pl is computed correctly, not by naively dropping the first label.
3. Explicit wildcard - if a verified domain is stored as *.example.com, any subdomain of example.com matches.

Server-to-Server Calls Are Always Allowed

A request without an Origin header - which is how server-to-server calls (curl, backend HTTP clients, webhooks) normally work - is always allowed through the CORS check. This check exists specifically to constrain browser requests; it has no bearing on /v1/* calls authenticated with your Secret Key via Basic Auth. If you're getting a "403 Origin not allowed" from a server-side integration, the cause is something else (check your HTTP client isn't setting an Origin header, which some do by default) - see HTTP API for the correct server-side request shape.

Fixing It

1. Go to Workspace settings → Tracking & domains and confirm the domain the page is served from - not just your tracking subdomain - is added and shows Verified.
2. If the page is served from a different subdomain than the one you verified (e.g. you verified axi.shop.com but the storefront is on checkout.shop.com), no action is needed as of 2026-08-05 as long as both share the same registrable domain - the sibling-subdomain rule above covers it automatically.
3. If the storefront domain does not share a registrable domain with any verified domain (e.g. a separate checkout domain on a different TLD, or a staging environment on an unrelated domain), add and verify that domain explicitly, or ask support about a wildcard entry.
4. Confirm the public key used to initialize the SDK belongs to the workspace that has the domain verified - a mismatched public key will look like a CORS failure but is actually an unknown workspace.