I’m building a custom utility script to sync queue data into our internal dashboard. The requirement is to pull every queue from every division, not just the default one. I’m using the @genesyscloud/purecloud-platform-client-v2 package in a Node.js environment. I figured I’d just loop through the divisions and call the list endpoint for each.
Here is the logic I’ve got so far:
const { PlatformClient } = require('@genesyscloud/purecloud-platform-client-v2');
const client = PlatformClient.create();
async function getAllQueues() {
const divisions = await client.DivisionApi.getDivisions();
const allQueues = [];
for (const div of divisions.records) {
let pageNumber = 1;
let hasNext = true;
while (hasNext) {
// This is where it gets tricky
const queues = await client.QueueApi.getQueues({
divisionId: div.id,
pageSize: 250,
pageNumber: pageNumber
});
allQueues.push(...queues.records);
if (queues.hasPreviousPage) { // Wait, is it hasPreviousPage or hasNextPage?
hasNext = true;
pageNumber++;
} else {
hasNext = false;
}
}
}
return allQueues;
}
The issue is the loop never breaks. It just keeps fetching page after page. I’m hitting the rate limit pretty fast. I checked the SDK docs but the pagination properties seem inconsistent between different resources. Sometimes it’s hasNextPage, sometimes I see hasPreviousPage which makes no sense for forward pagination.
Also, I noticed that if a division has zero queues, the API returns an empty array but doesn’t set a clear flag to stop. So the while loop spins forever on empty divisions. I tried checking queues.records.length === 0 but that feels wrong because page 1 might legitimately be empty if all items are on page 2? No, that can’t be right.
What’s the correct property to check for end of list in the JS SDK? And is there a better way to handle the division iteration without blocking the event loop? I feel like I’m missing a helper method.
you’re probably running into the classic pagination trap where the SDK expects a specific pattern to keep fetching pages, and if the loop condition isn’t tight, it just spins or stops early. the getQueuesQueues method returns a response object that has a nextPage property. you don’t really need to manually loop through divisions first unless you’re filtering hard, but if you are, make sure you’re handling the async nature of each division’s fetch correctly.
here’s how i usually structure this in a utility script. it’s a bit verbose but it handles the pagination cleanly and lets you process each queue as it comes in.
const { PlatformClient } = require('@genesyscloud/purecloud-platform-client-v2');
async function getAllQueuesAcrossDivisions(platformClient) {
// first, get all divisions. this is usually quick.
const divisionsResponse = await platformClient.DivisionApi.getDivisions();
const divisions = divisionsResponse.body.divisions;
const allQueues = [];
// loop through each division
for (const division of divisions) {
let nextPage = null;
// inner loop for pagination within this division
do {
// the SDK method usually takes a divisionId and optional nextPage
// note: the exact method signature might vary slightly by SDK version
// but typically it's getQueuesQueues({ divisionId: division.id, nextPage: nextPage })
const response = await platformClient.QueueApi.getQueuesQueues({
divisionId: division.id,
nextPage: nextPage
});
// add the current batch of queues
if (response.body.entities && response.body.entities.length > 0) {
allQueues.push(...response.body.entities);
}
// check if there's more data
nextPage = response.body.nextPage;
} while (nextPage); // keep going while there's a next page token
}
return allQueues;
}
the key bit is that do...while loop. if you just call getQueuesQueues once per division, you’ll only get the first 25 or so queues (default page size). the nextPage token in the response body is your ticket to the next batch.
also, watch out for rate limits if you have a ton of divisions. the SDK handles retries for 429s pretty well, but if you’re hammering it, you might want to add a small setTimeout between division calls. i’ve seen it hang when the backend gets overwhelmed by rapid sequential calls across many divisions.
one thing that trips people up is assuming the entities array is always present. sometimes an empty division returns an empty array, so the check if (response.body.entities && response.body.entities.length > 0) saves you from pushing undefined into your final array.
i’d also recommend logging the division ID when you start fetching, just so you can see where it might stall if it does.