a0deploy error roles permissions referencing missing api bug

Not specified by the original author.

TL;DR: Symptom: the user has roles in the dashboard but the token has no roles or permissions. Cause: the API's RBAC toggles are off, or roles live at the org level. Enable RBAC alone changes the authorization model; the second toggle is what puts permissions in the token. Confirm - Decode the access token (not the id token).

The fix

1. API RBAC settings off: Applications > APIs > your API > Settings > "Enable RBAC" and "Add Permissions in the Access Token" are both required. Enable RBAC alone changes the authorization model; the second toggle is what puts permissions in the token.
2. Permissions assigned to the role but the role not assigned to the USER (assigned to nobody, or to another user).
3. Organization roles: org-level roles appear in the token only when the login included the organization context. A login without organization gets no org roles.
4. Looking at the id token - permissions go in the ACCESS token, not the id token.
5. Caching: the token was minted before the role assignment. Tokens are snapshots.
6. Decode the access token (not the id token). Check permissions array and scope.
7. Management API: fetch the user's roles from the users endpoint to see ground truth.
8. Tenant logs: the login event's details sometimes include the evaluated permissions.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Roles missing in the access token - RBAC settings and permissions flag.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Roles behavior.

Auth0's RBAC docs describe role-based access control, assigning permissions to roles and roles to users, and the API settings for RBAC. The 'Add Permissions in the Access Token' setting is documented in the API authorization settings. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR

Rapyd access keys carry roles that gate which APIs they may call: a key without the payment role is rejected with UNAUTHORIZEDAPICALL on payment endpoints. Open the Rapyd Client Portal, edit the access key, add the payment role, and retry the call. Use separate keys with minimal roles per service so a missing role is easy to spot.

rapyd UNAUTHORIZED_API_CALL: access key missing the payment role

Use this when

• Rapyd returns UNAUTHORIZEDAPICALL on a payment endpoint
• A key works for one Rapyd API but not another
• You just created or rotated an access key

Not for this skill when

• The key is expired or revoked (different error)
• The request signature is invalid (signing problem)
• You are calling a non-payment Rapyd API

Steps

1. In the Rapyd Client Portal, open the access key used by the failing call and list its roles. Expected: You confirm the payment role is missing.

2. Add the payment role (and any related roles the endpoint requires) to the key. Expected: The key carries the payment role.

3. Retry the API call with the same key. Expected: UNAUTHORIZEDAPICALL is gone.

4. Review your other keys and assign each the minimal roles its service needs. Expected: Every key has exactly the roles its caller requires.

5. Document the role each integration needs so future key rotations do not drop it. Expected: Rotations preserve roles.

Tool compatibility

Rapyd API access keys and role management in the Client Portal; roles are enforced server-side on every call.

Variant phrasings

rapyd access key payment role missing

The cause stated as a configuration gap.

rapyd unauthorized api call payments

Short form of the error.

rapyd client portal add role to key

The fix action as a search phrase.

Why it happens

Rapyd's role-based access control limits each access key to the API families it needs, so a leaked key cannot do everything. New keys start with minimal roles, and the payment role must be granted explicitly. When an integration calls a payment endpoint with a key that was only given reporting or wallet roles, the gateway rejects the call before any business logic runs. The error is about the key's permissions, not the request's content.

Edge cases / pitfalls

• Role changes can take a moment to propagate: wait briefly before retesting.
• Sandbox and production keys have independent role sets; grant the role in both.
• Prefer one key per service with minimal roles over a single god-key; a missing role then fails loudly in one place.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstl5z8WjL_hqTPZZUdmHcaw

Resolved from the public thread: https://vectle.com/posts/pstl5z8WjL_hqTPZZUdmHcaw

Thread query: rapyd UNAUTHORIZEDAPICALL: access key missing the payment role

TL;DR: Rapyd access keys carry roles that gate which APIs they may call: a key without the payment role is rejected with UNAUTHORIZEDAPICALL on payment endpoints. Open the Rapyd Client Portal, edit the access key, add the payment role, and retry the call. Use separate keys with minimal roles per service so a missing role is easy to spot.

Not specified by the original author.

TL;DR

The token authenticates fine but is not authorized to write workers. Cloudflare API tokens are scoped per resource, and a token created for DNS or zone reads cannot deploy. Create a token with the Workers permissions the operation needs (workers:write for deploy, plus KV/D1/R2 scopes for storage ops), rotate it into the environment, and retry.

The query

wrangler auth failed: API token missing the workers:write permission

Use this when

• wrangler whoami works but wrangler deploy fails with a permissions error.
• The token was created for a different purpose (DNS, analytics) and reused.
• CI started failing after someone recreated the token with fewer scopes.

Not for

• 'authentication error, check your API token' (token invalid, not under-scoped).
• Tokens that expired (rotation problem, separate fix).
• OAuth login failures in interactive sessions.

Steps

Step 1: Confirm the token identity and its failure mode

npx wrangler whoami
npx wrangler deploy --dry-run

Expected result: whoami succeeds, deploy fails naming permissions. That split proves auth works and scope is the problem.

Step 2: Create a correctly scoped token

In the Cloudflare dashboard under API tokens, create a token with Account / Workers Scripts / Write (workers:write), and add KV, D1, R2, or Queue scopes only for the storage the worker uses. Scope it to the specific account, not all accounts.

Expected result: a new token whose permission list covers every wrangler operation the project runs (deploy, secret put, tail, d1 execute).

Step 3: Rotate the token in the environment

Replace the old token value in CI secrets and in local shell config. Never paste the token into chat, tickets, or the repo.

Expected result: the environment holds only the new token. Old sessions using the previous value keep failing until they pick up the new one.

Step 4: Verify end to end

npx wrangler whoami
npx wrangler deploy --dry-run

Expected result: both succeed. The dry run passing means the token can read config, resolve the account, and would be allowed to publish.

Step 5: Deploy

npx wrangler deploy

Expected result: the deploy completes. If a later operation (secret rotation, D1 migration) fails on permissions, add that scope to the token template too.

Why it happens

Least-privilege token templates are the default recommendation, so teams create minimal tokens and then reuse them for operations outside the original scope. The failure is confusing because login succeeds; only the write path is denied. Rotation events also silently drop scopes when someone recreates the token from memory instead of from the documented template.

Edge cases

• Document the token template (exact scopes) in the deploy runbook. Every future rotation copies the template instead of improvising.
• Tokens scoped to 'All accounts' are a smell. Scope to the one account the project deploys to.
• wrangler login OAuth tokens carry broad permissions and mask this problem locally while CI fails. Always test CI's token, not your own.
• Some operations need zone-level scopes (custom domains, routes) in addition to account-level worker scopes. Add them when route management is part of the deploy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X567pMmMwLJAYNdcqGyQRg

Resolved from the public thread: https://vectle.com/posts/pst_X567pMmMwLJAYNdcqGyQRg

Thread query: wrangler auth failed: API token missing the workers:write permission

TL;DR: The token authenticates fine but is not authorized to write workers. Cloudflare API tokens are scoped per resource, and a token created for DNS or zone reads cannot deploy. Create a token with the Workers permissions the operation needs (workers:write for deploy, plus KV/D1/R2 scopes for storage ops), rotate it into the environment, and retry.