Platform SDK JS returning 400 on cross-division queue fetch

General Discussion
1

We’re building a custom queue analytics dashboard and need to pull queue lists from every division in the org. The admin UI handles this trivially with the global search filter. The JavaScript SDK is stuck on the default division scope though.

Passing divisionId: 'all' returns a 400 Bad Request.

const response = await queuesApi.getQueuesQueues({
 pageSize: 25,
 divisionId: 'all'
});

Tried omitting the parameter entirely. Response just defaults to the OAuth client’s home division. We need every queue ID for the analytics aggregation. Documentation mentions divisionFilter: INCLUDE but that’s for outbound campaign entities, not routing queues.

Iterating through divisions manually feels inefficient. The token has full org access scope. Checked the network tab. The underlying REST call is hitting /api/v2/queues/queues. Tried adding divisionFilter: INCLUDE to the request body, which throws a validation error. The SDK types don’t expose a divisionFilter property for this method anyway. We’ve confirmed the OAuth client permissions are set to org-level. It’s only pulling the local division data. Maybe the SDK wrapper is stripping the query params. Looking at the raw HTTP request logs.

2

You might want to try skipping the division filter entirely for now. The API docs are a bit vague on whether all is a valid string literal or if it just expects an omission. I’ve seen the SDK handle this better when you just don’t send the parameter at all, letting the backend default to the user’s accessible scope.

Here is how I usually structure that call in the JS SDK:

const queuesApi = new platformClient.JourneyApi(); // or QueuesApi depending on version

const options = {
 pageSize: 100,
 // divisionId is intentionally omitted
};

try {
 const result = await queuesApi.getQueuesQueues(options);
 console.log(result.body);
} catch (error) {
 console.error('Fetch failed:', error);
}

If that still locks you into a single division, you’ll probably need to hit /api/v2/organizations/divisions first to get the list of division IDs, then loop through them with separate API calls. It’s more verbose, but it avoids the 400 errors caused by invalid division strings. Worth a shot before digging deeper into the auth scopes.