First-party · SDK from edge
SDK and every ID5 call served first-party from edge.pakopress.dev (same registrable domain as the page). First-party topology on the page's own registrable domain.
Third-party · SDK from edge
SDK and calls served from the ID5-hosted edge edge.eu-2-id5-sync.com (third-party). Third-party topology; for partners without the publisher's domain.
First-party · SDK from jsDelivr
SDK loaded from jsDelivr (neutral CDN); dynamic calls go first-party to edge.pakopress.dev. The edge handles only the calls.
apiBaseUrl ready in SDK 1.0.98)Third-party · SDK from jsDelivr
SDK loaded from jsDelivr; dynamic calls go to the ID5-hosted edge edge.eu-2-id5-sync.com (third-party).
apiBaseUrl (SDK pinned 1.0.98)Third-party · proxy on a blocked domain
SDK and calls via proxy.eu-1-id5-sync.com, whose registrable domain eu-1-id5-sync.com is subject to request blocking. Control case: the proxy host itself must not be a blocked domain.
First-party CNAME cloaking → blocked domain
First-party cloak.pakopress.dev, grey CNAME → blocked proxy.eu-1-id5-sync.com. Tests whether request blocking follows the CNAME chain or passes the first-party forward name.
/a7q3 is the per-deployment proxy prefix. The first-party pages need an edge on
edge.pakopress.dev/a7q3/*; the third-party pages need edge.eu-2-id5-sync.com/a7q3/*.
partnerId: 173 is a placeholder; consent is static for the demo.
Two routing mechanisms. The SDK from edge pages let the edge rewrite the
hard-coded ID5 hosts inside id5-api.js, so calls follow the SDK file to the edge — works with any
published SDK. The SDK from jsDelivr pages load an unmodified SDK and instead pass
apiBaseUrl to ID5.init, which routes the calls; this needs an SDK build that supports
apiBaseUrl (available from 1.0.98 — pinned here while the floating @1 cache still serves an older build).