API key management
An API key is an application credential. It belongs to one workspace, and an application holding it can call the Bird API within its assigned scopes. You can manage keys in the dashboard or through the API. For the full technical contract, see Authentication & API keys.
Where keys live
Open API keys, pinned near the bottom of the sidebar alongside Webhooks and Logs. The page lists each key's name, masked prefix, scopes, status, expiration, and last-used date.

Creating and revoking keys requires the right workspace role: Admins and Developers have it. See Users, teams & roles.
Creating a key
- On the API keys page, choose to create a new key.
- Name it for its job, such as "Billing service production," rather than for a person.
- Pick scopes. Each scope has a read or write level. Grant only the scopes and levels the application needs.
- Create the key and copy the secret immediately.
The secret is shown once
The full key appears once, when you create or rotate the key. Bird cannot show the secret again. Copy it directly to a secret manager or deployment configuration. If you lose it, rotate or replace the key.
A key's scopes cannot be edited. To change them, create a replacement key, update the application, and revoke the old key.
Revoking a key
Revoke a key when it is no longer needed or you suspect it leaked. Revocation is permanent. Key validation uses a short-lived cache, so a revoked key may keep working for up to five seconds before requests fail authentication.
If you suspect a key has leaked, revoke it and deploy a replacement. Requests fail until the application uses an active key.
To rotate without downtime, use the rotation action and keep its default 24-hour grace period. Deploy the replacement before the grace period ends. Set a shorter grace period only when you can update callers sooner.
Everything is recorded
Key creation, rotation, and revocation appear in your organization's audit log. Include revoked keys in the key list to review their metadata.
Good habits
- Use one key per application and environment. Separate staging and production keys so you can revoke one without affecting the other.
- Watch the last-used column. Revoke inactive keys that are no longer needed.
- Never put keys in client-side code or public repositories. Keys belong in server-side configuration and secret managers only.
Next steps
- Authentication & API keys: key anatomy, scope details, and the API contract
- Audit log: reviewing key creation and revocation events
- Users, teams & roles: who can manage keys