Teams, projects and roles
Four roles, what each can do, and how projects divide up keys and spend.
The four roles
Roles are a ladder, not a set of independent switches. Every permission is expressed as “at least this rank”, which keeps the checks total — there is no combination that falls through into an undefined answer.
| Role | Description |
|---|---|
| viewer | Read dashboards and activity. Changes nothing. |
| developer | Everything a viewer can do, plus creating and revoking API keys, using the playground and saving presets. |
| admin | Plus provider keys, limits, webhooks and projects. No billing. |
| owner | Everything, including billing, team membership and closing the account. |
What each can do
| Capability | Description |
|---|---|
| read | Dashboards, activity, analytics. Every role. |
| buildKeys | Create and revoke API keys, run the playground, save presets. Developer and above. |
| configure | Provider keys, spending limits, webhooks, projects. Admin and above. |
| billing | Top-ups, team membership, closing the account. Owner only. |
A refused action says which role would have been needed, rather than failing silently or with a generic permission error.
Projects
A project groups keys so that spend, activity and limits can be read per environment or per team rather than per account. An API key can be filed under one, at creation or later, including through POST /keys with project_id — which is verified against your own account, so a key cannot be filed under somebody else’s project.
Requests carry their key’s project id on the row, so Activity and Analytics can be sliced by it. For finer grouping than a project — by feature, tenant or release — metadata labels travel on the request itself.
SSO and SCIM are not built
Something here disagrees with what the API actually did? That is a bug in this page, and worth reporting.
Report it