403 Forbidden on /api/v2/routing/queues with seemingly correct OAuth scopes

NICE CXone API & Integrations
1
  • Node.js 18.17.0
  • Express 4.18.2
  • Genesys Cloud API v2
  • Region: us-east-1
  • Timezone: America/Chicago

Trying to understand why my Express middleware is receiving a 403 Forbidden response when attempting to fetch queue details via the API. I have successfully implemented the OAuth 2.0 client credentials flow and am receiving a valid access token. The token introspection endpoint confirms the token is active and valid.

However, when I make the following GET request:

const options = {
 method: 'GET',
 url: 'https://api.mypurecloud.com/api/v2/routing/queues',
 headers: {
 Authorization: `Bearer ${accessToken}`,
 'Content-Type': 'application/json'
 }
};

try {
 const response = await axios.request(options);
 console.log(response.data);
} catch (error) {
 console.error('Error fetching queues:', error.response.status, error.response.data);
}

The error response is:

{
 "errors": [
 {
 "code": "forbidden",
 "message": "You do not have the required permissions to perform this operation."
 }
 ]
}

I have assigned the following scopes to the application in the Genesys Cloud admin portal:

  • routing:queue:read
  • routing:queue:write
  • routing:skill:read
  • routing:member:read

I also verified that the user associated with the client credentials has the “Routing Manager” role, which should grant access to these resources. Interestingly, other endpoints like /api/v2/users/me work fine with the same token, provided I have user:read scope.

Is there a hidden scope requirement for listing queues? Or is this a known issue with the routing:queue:read scope not propagating correctly to the API gateway? I’ve tried regenerating the client secret and re-authorizing, but the result is identical. Any insights on what I might be missing here?

2

TL;DR: Check your service account’s specific permissions. Admin scope isn’t enough for queue reads if the account lacks routing:queue:read or belongs to an org admin role that’s been restricted.

Ah, this is a known issue. having admin in your scopes just means the token is valid for admin actions. it doesn’t mean the identity behind that token has permission to touch routing resources.

in my terraform pipelines, i see this all the time. the service account usually gets created with a generic “Org Admin” role, but Genesys Cloud has tightened up RBAC recently. that role often lacks direct access to /api/v2/routing/queues unless explicitly granted.

you need to verify two things:

  1. The OAuth application has the routing:queue:read scope enabled.
  2. The service account user has a role with actual queue read permissions.

try this quick curl to test the token directly, bypassing your express middleware to rule out code issues:

curl -X GET "https://api.mypurecloud.com/api/v2/routing/queues" \
 -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
 -H "Accept: application/json"

if that returns 403, your code is fine. the problem is IAM.

go to Admin > Security > Roles. find the role assigned to your service account. check if it includes “View all queues” or similar. if not, create a custom role with just routing:queue:read and assign it.

also, double-check that the service account isn’t locked to a specific organization unit that doesn’t contain the queue you’re querying. the api respects OU boundaries hard.

i usually automate this check in my CI pipeline. if the plan fails with 403, i trigger a terraform refresh on the genesyscloud_user resource to ensure the role assignments are synced. saves hours of manual debugging.

check the role first. it’s almost always the role.

3 Likes
3

yep, the 403 is usually a permissions mismatch. i’ve seen this a dozen times. you need routing:queue:read explicitly. just admin isn’t enough for queue data.

here’s the curl to check your token scopes:

curl -X POST "https://api.mypurecloud.com/api/v2/oauth2/introspect" \
 -H "Content-Type: application/x-www-form-urlencoded" \
 -H "Authorization: Basic <base64(client_id:client_secret)>" \
 -d "token=<your_access_token>"

look for routing:queue:read in the scopes array. if it’s missing, add it to your client app. also check the service account role. it needs at least a routing read permission set. sometimes the org admin role gets stripped of routing perms by policy.

i usually just add the routing:queue:read scope and re-auth. works every time.

4

look, i don’t usually touch the oauth layer, but i’ve seen this pattern before in notification api implementations. the issue isn’t just the scope string. it’s the service account role assignment. routing:queue:read is necessary, yes, but if your service account is attached to a custom org admin role that has explicit exclusions, you’ll get a 403 even with a valid token.

also, check the region. you mentioned us-east-1 in your stack, but are you hitting api.mypurecloud.com or api.us-east-1.pure.cloud? mixing these up causes 403s because the token is valid for one tenant context but not the other.

here’s how i verify the actual permissions granted to the token, not just what you requested:

const axios = require('axios');

async function checkEffectivePermissions(token) {
 try {
 const res = await axios.get('https://api.mypurecloud.com/api/v2/authorization/permissions', {
 headers: {
 'Authorization': `Bearer ${token}`,
 'Accept': 'application/json'
 }
 });
 
 // Check if routing:queue:read is actually present in the response
 const hasQueueRead = res.data.some(p => p.permission === 'routing:queue:read');
 console.log('Queue Read Permission:', hasQueueRead);
 
 return hasQueueRead;
 } catch (error) {
 console.error('Permission check failed:', error.response?.status, error.response?.data);
 }
}

if this returns false, your role config is wrong. fix the role first. don’t keep tweaking the code. the api is telling you exactly what’s wrong. stop guessing.

5

watch out for the region endpoint. if your token is from api.mypurecloud.com but you’re hitting api.us-east-1.mypurecloud.com, the 403 is a red herring for a cross-region mismatch. also, routing:queue:read won’t save you if the service account isn’t assigned to the specific org unit containing those queues. check the OU hierarchy.