Call the tenant host directly

If you cannot route /edgekit/ on your own domain, your pages can send EdgeKit requests to the tenant host itself, such as https://your-tenant-host/edgekit/v1/decide. The browser client does this when you set its baseUrl (BrowserClientOptions).

Keep the /edgekit/v1/ path on the tenant host too. The browser credential (the site header and the origin check) is on /edgekit/v1/ paths on either host. On the tenant host, /v1/decide takes an API key and refuses a browser with 401.

What you lose

• One session for both hosts, unless your organization’s cookie domain covers both. By default the sign-in cookie is host-only: it stays on the host the user signed in through. When your pages sign in through the tenant host, and the tenant host shares your site’s domain, such as edgekit.example.com for www.example.com, later requests to the tenant host keep the session. A session started on your own host, through the /edgekit/ path, is not sent to the tenant host. With a cookie domain such as example.com, one session serves both hosts. A tenant host on another domain never gets the cookie. Without a session, decide still answers 200, as for an anonymous device, with no error, and requests that need a signed-in user answer 401 unauthorized.
• Same-origin requests: every request is cross-origin, so the browser sends a CORS preflight first. Add the tenant host to your Content Security Policy’s connect-src.
• First-party analytics: to send events to the tenant host, set the tracker’s collectorOrigin to the tenant host and its pathPrefix to an empty string (EdgeKitTrackerOptions). The collector answers there at /a/t, without the /edgekit prefix. Events then go to a host other than your page’s own.

How cross-origin requests are checked

1. The preflight: the tenant host answers a preflight from any origin, for the methods the route serves. It allows the request headers content-type and x-edgekit-site-id, and decide also allows x-edgekit-preview. A browser may reuse the answer for 10 minutes. The preflight grants nothing: it cannot see which site is asked for.
2. The request: the real request names its site in x-edgekit-site-id, and its Origin is checked against that site’s allowed origins. An allowed origin gets Access-Control-Allow-Origin with its own value, and Access-Control-Allow-Credentials: true.
3. A refusal answers 403 forbidden with no CORS headers, so the browser reports a CORS error and your code cannot read the body.

The browser cannot send an Authorization header to the tenant host: the preflight does not allow it. API keys belong on servers.

/edgekit/v1/id/config and /edgekit/v1/id/traits skip the origin check: they carry no credential and answer Access-Control-Allow-Origin: *.