Authentication

Every call carries a bearer token. Its prefix tells you the environment; its scopes tell you what it may do.

Bearer token

Authenticate with the Authorization header on every request. Create tokens in the panel — the secret is shown once, at creation, and never again. We only ever store a prefix, a hash and the last characters, so a leaked database cannot reconstruct your token.

http

Authorization: Bearer qsy_live_91fb5d2dc31fd065...

The prefix marks the environment. qsy_test_ exercises the whole pipeline — including webhooks — without reaching a real recipient or spending balance. qsy_live_ reaches real inboxes and is billed.

Scopes and roles

Authorisation is the intersection of two axes: what the token may do (its scopes) and what the person who created it may do (their role). A read-only member cannot mint a sending token, and a sending token created by an owner is still limited to sending.

Scope	Grants
email:send / email:read	Send email and read its messages, events and status. Suppressions follow the same split: list with email:read, add and remove with email:send.
sms:send / sms:read	Send SMS and read segments, events and status. Suppressions follow the same split. sms:send also starts and checks one-time-code verifications.
email:domains	Register and verify sending identities — domains and single senders.
webhooks:manage	Register endpoints and inspect deliveries.

Give each integration its own token with the narrowest scope it needs. Revoking one then never touches the others, and a leaked read token can never send.

Previous Overview Next Idempotency