How permissions work
Every operation requires a set of permissions, named in kebab case after what they allow (view-consumer-catalog, create-consumer-redemptions, manage-webhooks). A request is allowed when its principal holds all of the operation’s permissions.
- Dashboard users hold the permissions of all their groups plus the permissions given to them directly, within one partner (Members and groups).
- API keys hold exactly their scopes, chosen when the key is created. A key never inherits the permissions of the user who created it.
- Some permissions are not delegable: they cover identity and security administration, payment authorisation and accepting prices, and can never be API-key scopes. Operations that need one can only be called by signed-in dashboard users.
403 missing-permission; more.requiredPermissions lists what the operation needs:
create-consumer-redemptions · API keys: allowed. A few workspace reads (for example workspace branding) show “none (any member or API key)”. Operations marked API keys: not allowed display the note “Dashboard session only”.
GET /partner/v1/principal returns the effectivePermissions of the calling key or user, and GET /partner/v1/permissions lists every permission that applies to your partner.
Choosing scopes
Give each key the smallest set of scopes its system needs, and use separate keys for separate systems.
Subscribing a webhook endpoint to billing events also needs
view-consumer-billing, and to pricing events view-consumer-pricing, on the key or user that creates or edits the endpoint.
Permission reference
Workspace permissions (every partner)
Consumer permissions
Default groups
Every consumer partner starts with these groups. You can create your own groups as well (Members and groups).