Authentication
Secure your API requests
Every API request needs to be authenticated with an API key passed via an HTTP header.
Recommended
Alternative
Never expose API keys in client-side code. Keep them in environment variables and call the API from your backend.
A key belongs to one workspace
An API key is bound to the workspace that was active when you created it, and that binding is fixed for the life of the key. There is no header or request parameter to make a key act as a different workspace.
- Personal key — created from your personal workspace. Only you can use or see it. Usage counts against your individual plan (free / starter / pro).
- Team key — created while a team workspace is active. Shared by every member of that team, usage counts against the team owner's plan, and it is visible to the team's owner and admins. Revoking a team key breaks every member's integration at once.
The dashboard's key list shows which workspace a key belongs to. If you are not sure, check there before wiring a key into production — a personal key cannot be moved to a team later.
Rotating a key with zero downtime
- Create a new key in the same workspace.
- Deploy it to every service that uses the old key.
- Confirm traffic is flowing on the new key (check the key's analytics).
- Only then revoke the old key.
Revocation takes effect within about 5 minutes (auth results are cached briefly; disabled
and expired keys are never cached). There is no grace period — a revoked or expired key
immediately returns 401 on its next request.
Expiring keys
Setting expires_in_days at creation is a hard expiry. The first request after
the expiry time fails with 401 "API key has expired", and the key is
auto-deactivated at that point — there is no renewal and no advance warning beyond the
entry in your activity log. If you use expiring keys, put the rotation date on a calendar.