authentication & keys

bearer tokens. scoped. rotate them. we check the signature and the ip shape; nothing exotic.

the header

authorization: bearer sk_live_01HXYZ9KQ7W3M5N2…

present on every request. tls only. if you make an http request, we redirect once and then start refusing.

key formats

prefix	scope	where to use
`sk_live_…`	full server-side	your backend only. 32 bytes base32.
`sk_test_…`	sandbox	anywhere. no billing, no real sends.
`pk_live_…`	publishable	browser. can read public event data, create orders. can't read pii.
`sk_restricted_…`	custom scopes	per-resource acl. create in studio.

scopes (on restricted keys)

restricted keys take a list of scopes. useful for integrations where you want a vendor to only read scan events:

{
  "scopes": [
    "events:read",
    "scans:read",
    "scans:write"
  ]
}

available resources: events, tickets, orders, attendees, payouts, scans, webhooks, venues. verbs: read, write, *.

rotation

every key has a grace period. when you regenerate, the old key stays valid for 24 hours so your deploys don't strand pods on old secrets. you can shrink this to zero in settings → security.

idempotency

every POST accepts an idempotency-key header. sending the same key within 24 hours returns the original response. use a uuid per semantic operation:

idempotency-key: 9f8c2b0a-order-2026-05-17-evt-01HY

webhook signatures

separate from api keys: webhook signatures use an endpoint secret that is generated when you add the url. see webhooks for verification code.

heads up

we email you when a key hasn't been rotated in 180 days. not because it's compromised — just good hygiene. if you rotate on a schedule, you can mute this.