Where the embed is served
The embed is served from a versioned path,https://embed.pulse.shiga.io/v1/
by default. The path is versioned, not the assets: breaking bridge/protocol
changes go to a new version (/v2/) — the version you’re integrated against
keeps working for you indefinitely, with no upgrade required on your side.
Content-Security-Policy the embed serves
frame-ancestorscontrols which pages are allowed to embed the iframe. It’s*today — any partner page may embed it. The hardened end-state is a per-partner allowlist: the embed host reads your registered origin(s) from your partner config and emitsframe-ancestors <your origins>instead. Once that ships, make sure the origin(s) you embed from are registered.connect-srclists every API host the embed calls:api.pulse.shiga.ioin production,sandbox.api.pulse.shiga.iofor sandbox integrations (see Sandbox).- The session token arrives in the URL fragment — it is never sent to the
server, never appears in access logs, and
Referrer-Policy: no-referrerkeeps it out of outbound referrers. You don’t need to do anything extra to protect it beyond not logging the full URL yourself.
Already handled for you
- The iframe is mounted with
sandbox="allow-scripts allow-same-origin allow-forms allow-popups"— no top-navigation, no downloads. You don’t set this yourself; the SDK applies it when you callmount(). - The postMessage bridge between your page and the iframe is origin-checked in both directions.
mount()rejectssk_keys outright, and firesembed_load_timeoutif the embed never becomes ready — both fail loudly rather than silently degrading.
Hosting Tier B on your own subdomain
If you serve the hosted page from your own subdomain (for examplepay.yourapp.com) instead of redirecting to the Pulse-hosted
URL: CNAME your subdomain to the embed host. A TLS certificate is provisioned
per partner domain, and you get the same build, served with layout=page —
see Hosted page (Tier B) for the query parameters and
Embedded iframe (Tier A) if you’re mounting the
component directly instead.