Here’s the current implementation we’re running to grab all queues:
const { PlatformClient } = require('@genesyscloud/purecloud-platform-client-node');
async function getAllQueues(client) {
const allQueues = [];
let nextUri = '/api/v2/queues';
while (nextUri) {
const response = await client.routingApi.getQueues({
expand: 'memberCounts,skillCounts'
});
if (response.body && response.body.entities) {
allQueues.push(...response.body.entities);
}
nextUri = response.body.nextPageUri;
}
return allQueues;
}
We’re seeing an issue where the returned list only includes queues from the default division. We have about 50 queues spread across three custom divisions (div:ops, div:sales, div:support), but the SDK call only returns the ones in the root division. The nextPageUri logic seems fine since it handles pagination within a single division, but there’s no obvious way to iterate through all divisions without manually listing them first.
I tried adding a divisionId parameter in the options, but the SDK types don’t seem to accept it for getQueues, and passing it anyway results in a 400 Bad Request error saying the parameter is invalid. We need a way to fetch everything without hardcoding division IDs since new ones get created regularly.
Is there a hidden method or a different endpoint we should be hitting? We’re using version 1.0.23 of the Node SDK. The goal is to get a complete list for a reporting dashboard that needs to show queue wait times across the entire org, not just one slice of it. Right now we’re getting about 12 queues back when we expect over 50.
Also, the response time is pretty slow, taking around 4 seconds for the default division. If we do end up having to loop through divisions manually, we’ll need to be careful about rate limits. We’ve hit 429s before when polling too aggressively.
Any ideas on how to make the SDK respect all divisions or a workaround that doesn’t involve manual division enumeration? We’ve checked the docs but they’re pretty light on multi-division queries for queues specifically. The user context has full admin rights, so permissions shouldn’t be the blocker here.