Docs
API Tokens
How service tokens work, and how they're scoped.
Creating a token
From Settings → CLI & Tokens, any org member can generate a token for their own use — since it can only ever act as its creator, there's no elevated-access risk in letting anyone self-serve one. Give it a descriptive name; the raw token value is shown exactly once — copy it immediately, it can't be retrieved again. Only its SHA-256 hash is ever stored. Non-owners only see and manage their own tokens; the Owner can see and revoke every token in the org.
Identity-inheriting, not independent
A token isn't a separately-configured credential — it acts as its creator, with their live project access evaluated fresh on every request. If that person's access to a project changes or they leave the organization, every token they created is affected identically and immediately.
Hard-scoped to one organization
A token minted for one organization is rejected against every other organization its creator belongs to, even though the creator's own login works everywhere they're a member. This means a leaked CI/CD token has single-org blast radius, not account-wide blast radius.
Revoking a token
Revocation is immediate and irreversible — a revoked token is rejected on its very next use. Revoked tokens stay listed (with a Revoked badge) rather than disappearing, so there's a durable record of every credential that ever existed.