First-party mount FAQ

Why does EdgeKit answer on my domain instead of its own?

So that the page and EdgeKit share one origin. EdgeKit’s cookies, such as the user’s sign-in session, are then set on your site’s host, a browser that blocks third-party cookies keeps them, and decide knows who the user is. Same-origin requests also need no CORS preflight and no Content Security Policy change.

Does EdgeKit work when the browser blocks third-party cookies?

Through the mount or the site proxy, yes: every EdgeKit cookie is set by your own host. When your pages call the tenant host directly, the sign-in cookie works only when the tenant host shares your site’s domain, such as edgekit.example.com for www.example.com, because the cookie is then not third-party. On another domain, decide answers as for an anonymous device. See Call the tenant host directly.

Is /edgekit/v1/… the same API as /v1/…?

For sign-in, user organizations, grants and newsletters, yes: both paths answer the same requests with the same credentials. Decide, gift links and recommendations differ: /edgekit/v1/ takes the browser credential (the site header and the origin check) and /v1/ takes a site-pinned API key. Checkout exists under /edgekit/v1/checkout only. See What each /edgekit/v1 path carries.

Why can’t my pages call /v1/decide?

/v1/decide takes a site-pinned API key, and a key in a browser is a key anyone can copy. Your pages call /edgekit/v1/decide, which takes no key: the site header selects the site and the origin check admits the page. On that path a request body that names a userId is refused with 403, so a page cannot decide as another user.

Which EdgeKit routes are not available under /edgekit/?

Server routes that take an API key (/v1/id/upstream/*, /v1/content/sync, /v1/iglu/*), webhooks, the newsletter confirm and unsubscribe links, a publication’s public archive, and the API description and health routes. They answer on the tenant host only. The confirmation and unsubscribe links in newsletter emails always point at the tenant host, so they work whether or not a site has a mount.

Does the mount take over any of my site’s paths?

Only the ones under /edgekit/ that you forward. Paths such as /v1/ on your own domain stay yours. The site proxy is different: it receives every request for the host, and passes the ones that are not EdgeKit’s to your upstream unchanged.

Do I need to change my Content Security Policy?

Not for the mount: requests to your own origin are allowed by connect-src 'self'. The site proxy’s script is served from /edgekit/proxy.js on your own origin, so script-src 'self' allows it. The proxy’s panel is styled by an inline <style> element, so with the site proxy your style-src, or default-src when there is none, must allow 'unsafe-inline'. Otherwise the panel draws unstyled, and in overlay mode it no longer covers the page. If your pages call the tenant host directly, add it to connect-src.

Does my own site’s origin need to be in Allowed origins?

Yes. Browsers send Origin on a POST even when it is same-origin, and the site proxy’s decide call carries the page’s origin. Without your own origin in the list, those requests answer 403 forbidden, and the site proxy then serves every page whole.

Can an allowed origin be a wildcard, such as https://*.example.com?

No. Each entry matches one origin exactly: scheme, host and port. An entry containing * never matches anything. List each origin, up to 50 per site.

When does a change to Allowed origins take effect?

At the next deploy. Requests read the deployed site, not the draft. After you save, stage and deploy the draft on Delivery › Deployments › Versions.

Can several sites share one mount?

Every site of your organization is served by the same tenant host, so the same forwarding rules work on each site’s domain. Each site’s pages send their own site id in x-edgekit-site-id. The site proxy is one copy per site: its EDGEKIT_SITE_ID names the site it fronts.

Will content blockers block EdgeKit?

EdgeKit’s requests go to your own origin, so there is no third-party host for a filter list to match. The EdgeKit tracker also posts to /edgekit/a/t rather than the standard tracker path. EdgeKit cannot promise that no blocker ever matches a path on your domain.

Should my CDN cache /edgekit/ responses?

Honour the headers EdgeKit sends and add no caching of your own. Answers that depend on who is asking are Cache-Control: no-store. /edgekit/v1/id/config may be cached for 5 minutes by a shared cache, and varies on x-edgekit-site-id.

Can another organization reach my data through my mount?

No. Your tenant host serves your organization only, with its own database and its own sign-in instance. The site id on a request selects one of your own organization’s sites and nothing else, so a wrong or forged id answers 404 not_found.

Do search engines see the whole page behind the site proxy?

A request whose verified-bot category is in EDGEKIT_BYPASS_BOT_CATEGORIES gets the whole page, and decide is not called. The default category is Search Engine Crawler. A crawler that is not verified is treated like any other device.

Can a user read gated text behind the site proxy?

In three cases, yes:

• overlay mode: with no gated region found, the panel covers the page in the browser, and the gated text is still in the page source. Set EDGEKIT_BODY_SELECTOR, or mark the region with the edgekit-gated class. An EDGEKIT_BODY_SELECTOR that matches nothing on the page has the same effect.
• Loose text: in truncated mode, text directly inside the gated region, outside any child element, is not removed.
• Decide unavailable: when decide fails or misses its 2-second deadline, the proxy serves the whole page rather than take your site down.

Does the site proxy slow pages down?

Each HTML page it decides costs a fetch from your upstream and then a decide call, one after the other, and decide has a 2-second deadline. A page decide answered for is Cache-Control: private, no-store, so no shared cache serves it. Pages on EDGEKIT_IGNORE_PATHS, verified bots and non-HTML responses keep your own caching.

What happens to my site if EdgeKit is down?

With the site proxy, pages still load: a failed or slow decide serves the whole page, and only /edgekit/ requests answer 502. With the path mount, your pages are served as usual and only the EdgeKit requests fail. The browser client reports each feature as unavailable when decide does not answer within its timeout, 2 seconds by default.