Service accounts
Service accounts are identity containers for API keys. They represent non-human actors (CI/CD pipelines, scripts, integrations) that need to interact with the API.Create a service account
Authorization: Bearer YOUR_ACCESS_TOKEN. API-key callers must have service_account:create, and the caller must outrank the role assigned to the new service account.
List service accounts
API keys
Each API key is tied to an organization. User-owned keys inherit your current access within that organization. Service-account keys inherit the selected service account’s organization role and workspace/file grants. API key management endpoints accept either a user access token or an API key:Create an API key
service_account_id to create a service-account key:
X-API-Key instead of Authorization if the key has api_key:create; API-key callers must provide service_account_id.
The response includes the full API key string — store it securely, as it cannot be retrieved again:
principal_type is "user" and service_account_id is null.
Using API keys
Include the key in theX-API-Key header:
Revoking and deleting keys
Revoke a key to disable it without deleting:Permissions
API key management is controlled by organization role permissions:
Organization admins and owners include API key management by default. Custom roles can grant the granular permissions above.
Creating service accounts accepts either a user session or an API key with
service_account:create. Listing service accounts, changing service account roles, and deleting service accounts still require a user session with the matching service_account:* permission.
API keys inherit access from their user or service-account principal. API key management calls require api_key:view, api_key:create, api_key:revoke, or api_key:delete; service-account creation requires service_account:create.