Change an API key's scopes
Replace the scopes on an existing key, keeping the same secret — so a scope change doesn’t force you to redeploy a credential.
Mostly useful when we add a new scope: keys issued before it existed
don’t carry it, and calls that need it fail with insufficient_scope
even though nothing about your key is wrong. PATCH it instead of
rotating.
scopes is the complete set, not a delta — send every scope the
key should end up with. Unknown scopes are rejected, and the change
applies to your next request.
Revoked keys can’t be re-scoped; create a new key instead. A key can only be re-scoped by a credential in its own environment — a sandbox key can’t widen a live key.
Authorizations
Pass your secret key in the Authorization header as a Bearer
token: Authorization: Bearer sk_test_... (sandbox) or
Bearer sk_live_... (production).
Keys are created in the developer portal and the plaintext secret is shown exactly once at creation. Treat them like passwords — never embed them in mobile apps or front-end code.
Path Parameters
Body
The complete scope set the key should carry from now on.
1Response
The updated key.
Plain UUID v4 (e.g. 15a81d54-0471-...). No prefix is
applied today. SDKs should treat the value as opaque.
"15a81d54-0471-4f3c-9c1f-2f0a0c7b8d31"
sandbox, live First few characters of the key, safe to display in lists and logs (the rest is irrecoverable after creation).
"sk_test_a89d15d0"
read:clients, write:clients, read:connections, write:connections, read:accounts, read:transactions, read:statements, write:statements, read:checks, manage:webhooks, read:webhooks, write:webhooks, read:api-keys, write:api-keys active, revoked 