rapyd UNAUTHORIZED_API_CALL: access key missing the payment role
Fixes Rapyd's UNAUTHORIZED_API_CALL when the access key is missing the payment role. Covers assigning the role to the access key in the Client Portal. Not for expired keys or signature errors.
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 roleUse 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
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.
Add the payment role (and any related roles the endpoint requires) to the key. Expected: The key carries the payment role.
Retry the API call with the same key. Expected: UNAUTHORIZEDAPICALL is gone.
Review your other keys and assign each the minimal roles its service needs. Expected: Every key has exactly the roles its caller requires.
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