Authentication (API keys and OAuth)
The REST API and the MCP server accept two kinds of bearer credential: an API key you create in settings, or an OAuth 2.1 access token an app receives after you approve it. Both resolve to an account, carry a set of scopes, and are re-checked against team permissions on every request.
API keys
Create a key under Settings, choose the scopes it may use, and optionally give it an expiry date. The secret is shown once at creation and only its last characters are kept, so a lost key is replaced rather than recovered. Send it as an Authorization bearer header. Keys carry a recognizable prefix and a checksum, which lets secret scanners attribute a leaked key and lets the server reject a malformed one without a database lookup.
Team keys
A key can belong to a team instead of to you personally, created from the team's settings by a member allowed to manage API keys. A team key is confined to that one team: it can read and change that team, its members, its invitations, and its billing, and every other team is refused with a 403. It also cannot reach account-level operations — the account profile, sign-in sessions, creating a team, or managing API keys — which need a personal key. A key never grants more than its owner already has either: team permissions are evaluated on every request, so the key loses access the moment its owner does.
OAuth for apps and agents
Third-party apps and agent clients use the OAuth 2.1 authorization code flow with PKCE. The client discovers the endpoints, sends you to a consent screen that lists exactly what it asks for, and receives an access token plus a refresh token once you approve. Trusted integrations should use a stable Client ID Metadata Document or an operator-issued client ID. Open dynamic registration remains available as a compatibility fallback; every generated client ID is reviewed separately and starts unverified.
Scopes
Scopes are coarse, resource-level grants. They only ever narrow what the credential's owner can already do — they never add permission — and one catalog drives API keys, the consent screen, and the OpenAPI security schemes.
| profile:read | Read your account profile, sessions, and preferences. |
| profile:write | Update your account profile and revoke your sessions. |
| teams:read | List the teams you belong to and read their details. |
| teams:write | Create teams and change team details. |
| members:read | List the members of your teams. |
| members:write | Change and remove members of your teams. |
| invites:write | Send and revoke invitations to your teams. |
| billing:read | Read the subscription and billing status of your teams. |
| api-keys:read | List the API keys on your account and when they were last used. |
| api-keys:write | Create and revoke API keys on your account. |
Revoking access
Revoke a key, or an app's access, under Settings → API & MCP; revoking a grant also destroys the tokens issued under it. Credentials are cached briefly so requests stay fast, which means a revocation applies immediately where it was performed and reaches the rest of the network about a minute later.
Rate limits and errors
Authenticated REST requests and MCP tool calls share a limit of 300 requests per 60 seconds per credential. Failed authentication attempts are limited separately per IP address; going over either limit returns 429 with a retry-after header. Every REST response states the bucket it was charged against in RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset, so a client can pace itself before being refused. Every failure is an RFC 9457 problem document whose code member is a stable identifier rather than translated prose, so scripts and models can branch on it.