Documentation
Authentication
API keys are bearer tokens, shown once, revocable instantly, and scoped to what they may reach.
Send the key as a bearer token:
Authorization: Bearer ck_live_9f3Kq2mZ7pR4tX8bN1vC6dLw
X-API-Key: ck_live_… also works, if that suits your HTTP client better.
Keys are shown once. We store only a hash, so there is no way to retrieve one later. If you lose it, revoke it and create another.
Revoking is immediate. The next request using a revoked key fails. Nothing is cached.
Keys carry scopes. Everything under /v1/otp needs the otp scope.
| Result | Status | Meaning |
|---|---|---|
| No key, or a malformed one | 401 | Header missing, or not in ck_live_… shape |
| Unknown, revoked, or expired key | 401 | Identical response for all three, by design |
| Valid key, missing scope | 403 | Retrying will not help — create a key with the scope |
Handling keys well
- Keep the key server-side. Environment variable or secret manager, never a repository, a browser bundle, or a mobile app. See why the browser is never the caller.
- Name your keys for where they run — "Signup form (production)". You will want to know which one to rotate.
- Rotate by creating first. Create the new key, deploy it, then revoke the old one; revocation takes effect on the very next request.
A workspace can hold 25 active keys at a time. Confirm any key with a free GET /v1/ping before you go looking for delivery problems.