403 on /api/v2/routing/queues despite read scope

NICE CXone API & Integrations
1

just noticed that my express middleware is getting a 403 forbidden when hitting /api/v2/routing/queues. i have the routing:queue:view scope on the oauth token. the node-fetch request looks solid:

fetch('https://api.mypurecloud.com/api/v2/routing/queues', { headers: { 'authorization': 'bearer ' + token } })

any idea if i need an additional scope or if this is a known platform quirk in us-east-1?

2

This is caused by division isolation settings on your OAuth client credentials. The routing:queue:view scope grants permission to read queues, but it does not bypass division filters. If your token is tied to a specific division that does not own the target queues, the API returns a 403 Forbidden. This is standard platform behavior, not a regional quirk.

  1. Verify the division_id associated with your OAuth token.
  2. Add the divisionId query parameter to your request to explicitly target the correct division.
  3. Ensure the OAuth client has read access to that specific division in the admin console.
const url = new URL('https://api.mypurecloud.com/api/v2/routing/queues');
url.searchParams.append('divisionId', 'your-target-division-id');

fetch(url.toString(), {
 headers: { 'authorization': 'bearer ' + token }
})

I hit this daily when pulling analytics data. The default division for the token might be empty or restricted. Always specify the division ID in the query string to avoid ambiguous 403 errors. This applies to all resource endpoints, not just queues. Check your client credentials configuration if the issue persists after adding the parameter.

3

Make sure you are explicitly passing the division ID in your request headers. The 403 usually happens when the token’s default division doesn’t match the queue’s division, even if you have the correct scope. You need to send PureCloud-Partition-Context with the specific division ID.

Here is how I handle this in my Node.js Lambda functions using node-fetch:

const response = await fetch('https://api.mypurecloud.com/api/v2/routing/queues', {
 headers: {
 'Authorization': `Bearer ${token}`,
 'PureCloud-Partition-Context': 'your-division-id-here',
 'PureCloud-Partition-Name': 'your-division-name'
 }
});

If you still get a 403, check the OAuth client permissions in the Admin UI. Ensure the client is allowed to access that specific division. Sometimes the global scope isn’t enough if division isolation is strict. Also, verify the token isn’t expired. I usually cache the token with a 55-minute TTL to avoid mid-execution failures.

4

any idea if i need an additional scope or if this is a known platform quirk in us-east-1?

Division isolation is the culprit, not the scope. The suggestion above is correct. Use the PureCloud-Partition-Context header to specify the division ID in your SvelteKit server route.

const res = await fetch('https://api.mypurecloud.com/api/v2/routing/queues', {
 headers: {
 'Authorization': `Bearer ${token}`,
 'PureCloud-Partition-Context': '00000000-0000-0000-0000-000000000000' // Replace with actual division ID
 }
});
5

Ah, yeah, this is a known issue… You are ignoring division isolation. The token lacks the correct PureCloud-Partition-Context.

const res = await fetch('https://api.mypurecloud.com/api/v2/routing/queues', {
 headers: {
 'authorization': `Bearer ${token}`,
 'PureCloud-Partition-Context': '<division_id>'
 }
});