Service accounts
Non-human identities that own API keys: roles, suspension, per-plan limits, and when to use one instead of a personal key.
A service account is an identity for automation — CI, Terraform, a bot — that owns API keys without being tied to a person who might leave. It has a role (viewer, developer or admin) that bounds what any of its keys can be granted, a status of active or suspended, and a count of keys.
Working with them
- Create under Settings → Service accounts (owner/admin): name, optional description, role.
- Issue a key from API keys → New key and choose the service account as the Owner; scopes are limited by the account's role.
- Suspend (
POST …/service-accounts/{id}/suspend) disables every key it owns at once; reactivate restores them. Delete removes the account and its keys.
Routes: GET/POST /api/v1/auth/organization/service-accounts, GET/PUT/DELETE …/{id}, POST …/{id}/suspend, POST …/{id}/reactivate.
Limits
| Plan | Service accounts |
|---|---|
| Free | 0 (API access itself starts at Team) |
| Team | 2 |
| Pro | 10 |
| Enterprise | Unlimited |
The organization API policy can require that keys used against production monitors belong to a service account, so a personal key can never be the thing production depends on.