Security
KEYS AND BLAST RADIUS.
What a key can reach, how it is protected, and how quickly it stops working when something goes wrong.
How it works
Keys are stored hashed
We keep a SHA-256 hash and a short prefix, never the secret. The full key is shown once, at creation. If it is lost, rotate it.
One workspace, one key
A key is bound to the workspace that issued it and can never read another. Sandbox keys are bound to a showroom workspace and cannot touch live data at all.
Least privilege by scope
A key carries only the scopes it was given. A call outside them is refused with insufficient_scope, which names the scope it needed.
Rotation without downtime
Rotating issues a new secret while the old one keeps working for an overlap window, with the retiring key returning Deprecation and Sunset headers so you can see the cutover coming.
Expiry and revocation
A key can be given an expiry date, and revoking one takes effect on the next request. Both are recorded in the audit trail.
Leaks are revoked automatically
We participate in GitHub secret scanning. If a live key is pushed to a public repository, GitHub reports it to a signed endpoint on our side, the key is switched off immediately and the event is written to the audit trail.
Signed webhooks, both directions
Outbound deliveries and inbound events use the same HMAC-SHA256 scheme over <timestamp>.<body>, with a five-minute freshness window and replay protection.
Every call is logged
Method, path, status, request id, latency and the key used, visible to workspace admins in the app.
Scopes you can grant
account:read
Read the workspace the key belongs to and the key's own settings.
plans:read
Read media plans and omni-channel campaigns.
research:read
Read studies and published findings.
pixel:read
Read daily PixelBridge rollups.
events:write
Send server-side conversion and behaviour events into a PixelBridge pixel.
actuals:write
Push daily delivered impressions, clicks, conversions and spend back into a media plan.
webhooks:read
Read the delivery log for the workspace's outbound webhook endpoints.
webhooks:write
Send a past webhook delivery again with the same event id.
Your side of the line
Keep keys server-side
Never ship an API key to a browser or a mobile binary. For browser tracking use the pixel package, which carries no secret.
Verify before you trust
Check the webhook signature and the timestamp in constant time before you read the body, and treat the event id as your deduplication key.
Separate the jobs
One key per integration, with only the scopes that integration needs. Revoking one then never takes the others down.
Build in the sandbox
Sandbox keys run against a showroom workspace with real shapes and no real people, so a broken loop cannot corrupt live reporting.
Platform-wide posture, certifications and data handling live on the security page.