Analytics API paging returns empty pages after page 1

NICE CXone API & Integrations
1

The pageSize and pageNumber params in GET /api/v2/analytics/queues/realtime seem to ignore the limit after the first request. I’m pulling historical queue metrics for a custom dashboard. The first call with pageSize=50 returns 50 items and pageCount says there are 10 pages total. When I send the second request with pageNumber=2, the body is empty. The headers still show pageCount: 10, but items is an empty array []. I’ve tried resetting the startTime and endTime filters, but it doesn’t change the result. Is there a specific way to handle the offset or is the API broken for multi-page fetches?

GET /api/v2/analytics/queues/realtime?pageSize=50&pageNumber=2

Response for page 1 looks fine. Page 2 response:

{
 "items": [],
 "pageCount": 10
}
2

Realtime endpoints don’t work like that. You’re mixing up two different pagination models. The /analytics/queues/realtime endpoint returns a snapshot of the current state, not a historical list. It doesn’t support pageNumber or pageSize in the way you’re using them for historical data. That’s why page 2 is empty. The state changed between requests, or the endpoint simply ignores those params for realtime queries.

If you want historical queue metrics, you need to hit the details query endpoint instead: POST /api/v2/analytics/queues/details/query. This uses cursor-based pagination, not page numbers. You send a JSON body with your time range and filters. The response gives you a nextPage token. You feed that token back into the next request’s previousPage field.

Here’s the correct flow using the Genesys Cloud SDK:

const analyticsApi = new PureCloudPlatformClientV2.AnalyticsApi();

// First request
const query = {
 dateFrom: "2023-10-01T00:00:00Z",
 dateTo: "2023-10-01T23:59:59Z",
 size: 50
};

let response = await analyticsApi.postAnalyticsQueuesDetailsQuery({ body: query });
let allMetrics = [...response.entities];

// Handle pagination
while (response.nextPage) {
 const nextQuery = {
 ...query,
 previousPage: response.nextPage
 };
 response = await analyticsApi.postAnalyticsQueuesDetailsQuery({ body: nextQuery });
 allMetrics = [...allMetrics, ...response.entities];
}

Stop using pageNumber on realtime endpoints. It’s not designed for it.

3

nailed it. Realtime endpoints are snapshots, not lists. You’re treating a live state query like a historical archive. That’s a common trap.

Here’s how to actually get that data:

  • Swap the endpoint. Use GET /api/v2/analytics/queues/data instead. This is the historical endpoint that respects pageSize and pageNumber.
  • Check your date range. Realtime queries don’t need dates. Historical ones do. If from and to are missing or too wide, the API might throttle or return sparse data. Keep the window tight for testing.
  • Verify the filter. If you’re filtering by queue IDs, ensure they’re valid UUIDs. A single bad ID in the array can break the whole batch in some SDK versions.

Here’s the corrected curl for historical data:

curl -X GET "https://api.mynicecx.com/api/v2/analytics/queues/data?from=2023-10-01T00:00:00.000Z&to=2023-10-01T23:59:59.999Z&pageSize=50&pageNumber=2" \
 -H "Authorization: Bearer YOUR_TOKEN" \
 -H "Content-Type: application/json"

If you’re using the .NET SDK, it looks like this:

var result = await analyticsClient.PostAnalyticsQueuesData(
 from: DateTime.Now.AddDays(-1),
 to: DateTime.Now,
 pageSize: 50,
 pageNumber: 2
);

The pageCount header you saw on the realtime call is misleading. It often reflects the total number of queues in the org, not pages of results for a specific query. When you hit the historical endpoint, the pageCount in the response body will match the actual pages available.

Also, watch out for the 2MB response limit. If you pull too many intervals or queues, the API might truncate the list silently. Check the truncated flag in the response. If it’s true, you’ll need to break down your query by queue ID or narrow the time window.

Stop using realtime for dashboards that need trends. It’s just noise.