Genesys Analytics API paging object behaves unexpectedly with pageSize=1000

We’ve hit a wall trying to paginate through conversation analytics data using the Genesys Cloud Analytics API from our Kotlin backend. The goal is to fetch a large dataset without hitting rate limits, so I’m setting pageSize to 1000 in the request body. The initial call to /api/v2/analytics/conversations/details/query works fine, but the returned paging object doesn’t seem to update correctly for the next request. Specifically, pageNumber increments as expected, but pageCount stays at 1 even when there are clearly more records. I’m using the com.genesyscloud.platform.client SDK, and the request body looks like this: {"pageSize": 1000, "pageNumber": 1, "dateRange": {"startDate": "2023-10-01T00:00:00.000Z", "endDate": "2023-10-02T00:00:00.000Z"}}. The response headers include x-page-count: 1, which is confusing because we know there are thousands of conversations in that window. I’ve tried adjusting the pageSize down to 100, and suddenly pageCount reflects the correct number of pages. It feels like the API has a hard limit on what it considers a single page, or maybe the paging object is calculated based on a different internal threshold.

I’ve checked the documentation, and it says pageSize can be up to 1000, but it doesn’t explicitly mention how pageCount is derived when the maximum size is used. I suspect there might be a mismatch between the requested pageSize and the actual chunk size the server returns, causing the paging metadata to be off. I’ve also tried using the nextPageToken from the response, but that field is null when pageSize is 1000. The code snippet for the request is straightforward:

val request = AnalyticsConversationsDetailsQueryRequest.builder()
 .pageSize(1000)
 .pageNumber(1)
 .dateRange(DateRange.builder().startDate(startDate).endDate(endDate).build())
 .build()
val response = analyticsApi.analyticsConversationsDetailsQuery(request)

The issue is that subsequent calls with pageNumber 2 return empty results, even though the first page only had 900 records. Is there a known quirk with the paging object when using large page sizes, or am I missing a parameter that forces the API to recalculate the total count?