Scopes and least privilege on partner/v1

Scopes name capabilities

Each partner capability maps to a scope — reading applications, writing applications, reading decisions, provisioning payments, running identity checks. You name the scopes you want on the token request, and the minted token can only exercise those. A token that never asked for a payments scope simply cannot provision a payment link, so a leaked token is bounded by what it was allowed to do.

Why least privilege

The cost of over-scoping is entirely downside: a credential that can do everything is a credential that, if compromised, can do everything. Scope narrowly and a leaked secret is a contained incident, not a breach. This pairs with per-workload projects — run a separate project per integration so each has its own client, its own scopes and its own rate-limit bucket.

Rotating without downtime

Because scopes live on the credential, you can stand up a second client with the same scopes, cut traffic over, and retire the first — see rotating credentials. Never widen a live credential's scopes just to unblock a one-off task; mint a purpose-scoped credential instead and discard it after.

Frequently asked questions

What happens if I call an endpoint outside my scopes?

You receive an authorization error (a 403-class response) explaining that the token lacks the required scope. The request never reaches the underlying capability, so no partial action occurs.

Can I add scopes to an existing token?

No — scopes are fixed at mint time. Request the wider scope set on your next token request, or better, mint a separate purpose-scoped credential so your everyday token stays narrow.