Bearer tokens
All API requests must include a Bearer token in theAuthorization header:
401 Unauthorized error.
To check a key without touching any resources, call GET /v1/me — it requires
no scope and returns the workspace name, plan, scopes and environment behind
the key:
API key format
QRKit API keys use a prefix to indicate the environment:Test keys work identically to live keys and create real QR codes in your
workspace (marked internally as created by a test key), so you can verify
the full flow end to end. Delete test codes when you’re done — they appear
in your dashboard like any other code.
Scopes
Each API key has one or more scopes that control what it can access:Creating API keys
API keys are created from the QRKit dashboard (recommended) or via the Tokens API. API access requires a paid plan. When you create a key, the full key value is returned once. Store it securely — you won’t be able to see it again. The dashboard and API only show the key prefix (e.g.,qr_live_a1b2) for identification.
Key rotation
Rotate API keys using the Rotate endpoint or the dashboard. This creates a new key with the same name, scopes and expiry, and revokes the old one.Token management endpoints (
/tokens/*) are authenticated with your QRKit
dashboard session (a Clerk session JWT), not with an API key — a leaked API
key can never mint new keys.Key expiration
API keys can optionally have an expiration date. Setexpires_in_days when creating a key:
401 Unauthorized error. Create a new key or use rotation before the current key expires.
Security best practices
1
Use environment variables
Never hardcode API keys in source code. Use environment variables or a secrets manager.
2
Use test keys for development
Use
qr_test_ keys during development and CI/CD. Switch to qr_live_ only in production.3
Rotate regularly
Set up a rotation schedule for your production keys (e.g., every 90 days).
4
Minimize scopes
Grant only the scopes your integration needs. A read-only dashboard only needs
qr:read.
