Security model

How Auphere Embed keeps credentials out of your bundle and each client’s data isolated — the summary your security team will ask for.

API keys

Keys use the format ak_live_… (high-entropy, checksummed) so secret scanners recognize them if they ever leak.
We store only a SHA-256 hash — a key is displayed in plaintext exactly once, at issuance.
Rotation supports a grace window: the old key keeps working while you roll out the new one. Revocation is instant and fail-closed.
Your key lives only in your backend. If it appears in frontend code, rotate it immediately.

Session tokens

Short-lived (15 minutes) and scoped to one client with a fixed set of permissions.
Delivered to the iframe via postMessage with strict origin checks — never in URLs, never in cookies. No third-party-cookie dependencies.
Revoking the API key, suspending the partner or unlinking the client kills live tokens: every request re-checks, fail-closed.

Client isolation

The rule that makes cross-client access structurally impossible: the target workspace is chosen only when the token is minted — server-side, gated by your partner’s client mapping — and the widget API reads it only from the signed token. No browser input ever selects a workspace. One client cannot see another’s data, and one partner cannot see another partner’s clients.

The iframe boundary

The modal runs on embed.auphere.com, a separate origin — your page’s JavaScript cannot read or manipulate it, and it cannot touch your page.
Only the origins registered on your API key may embed the widget; all other origins are blocked at the CSP level (frame-ancestors).
WhatsApp credentials collected during signup are encrypted at rest and never transit through your frontend.

Abuse controls

Per-partner rate limits on token minting and widget APIs.
Broadcast audience caps per send.
An append-only audit log of partner activity.