Skip to main content

How permissions work

Every operation requires a set of permissions; a request needs all of them.
  • A dashboard user has the permissions of their groups plus their direct permissions in the partner (their effective permissions).
  • An API key has exactly its scopes, never the permissions of the user who created it.
A missing permission is 403 missing-permission; the error entry lists what was missing in more.requiredPermissions:
Each API reference page ends with Required permissions and API keys: allowed | not allowed. Operations that API keys can never call (security administration such as API keys, members, groups and the IP allowlist) answer 403 missing-permission to a key. One read needs no permission at all: the workspace branding (GET /partner/v1/branding/workspace) is readable by any member and any API key. GET /partner/v1/permissions lists the catalog with delegable and applicable flags.

Choosing scopes

Give each key only what its system does: Avoid reveal-provider-vouchers on keys unless a system really needs clear values: every reveal is audited.

Permission reference

Workspace permissions (every partner): Provider permissions (providers only): Consumer permissions exist for partners with the consumer role; they are documented on the consumer docs site.