Skip to main content
Scopes control what a credential can do. Grant the least access an integration needs. Each operation declares the scope it requires, and the API checks it on every request — holding a key or token is never enough on its own.

​
The catalog

There are eight scopes. Read scopes let a credential list and fetch; write scopes let it create or change content.

​
Read-only by default

A credential created with no scopes selected gets the read-only set:
Write access is always opt-in. There is no separate delete scope; the supported delete operation is governed by its resource’s write scope.

​
How scopes are enforced

  • API keys are granted a fixed set of scopes when you create them. To change scopes, create a new key.
  • OAuth connections, including the CLI and MCP clients, are granted scopes when you approve them on the consent screen. A client can request scopes, but you approve what it actually receives, and the grant is capped by your role in the workspace.
  • A request for an operation whose scope the credential lacks returns 403 forbidden, and nothing is read or written. Missing the read scope for a resource is also 403, even inside your own workspace.
Scope and workspace are separate checks. A resource in another workspace returns 404 regardless of scope, so an ID from another workspace never reveals whether your scopes would have allowed the operation.

​
Roles

Every scope in the catalog is available to any workspace member, including Moderators. Admin and Owner-only concerns — billing, team, domains, and key management — have no scope because they have no API operation. A credential whose creator is not a member of the workspace grants nothing.