refactoring our reporting pipeline to handle larger datasets from the Genesys Cloud Analytics API. The specific endpoint in question is POST /api/v2/analytics/users/summary. The requirement is to paginate through results efficiently without making unnecessary requests.
The documentation states that the request body should include a paging object containing pageSize and pageNumber. However, the response structure includes a paging object with pageSize, pageNumber, pageCount, and total. I am trying to understand the exact relationship between the input pageNumber and the output pageCount.
Here is the payload we are sending:
{
"groupBy": ["queueId"],
"paging": {
"pageSize": 25,
"pageNumber": 1
}
}
The response returns pageCount: 4. We assume this means there are four pages of data. When we increment the pageNumber to 2, 3, and 4, we receive data. If we request pageNumber: 5, the API returns an empty array for data but the paging object still shows pageCount: 4.
The issue arises when the total number of records is not evenly divisible by the pageSize. For instance, if there are 103 records and pageSize is 25, pageCount is 5. Page 5 contains only 3 records. We want to ensure we do not miss these trailing records or make an extra request to page 6 which returns nothing.
Is the pageCount in the response the definitive source of truth for the number of pages to iterate over? Or should we rely on the total field and calculate the pages ourselves? The current implementation iterates until pageNumber equals pageCount. This seems correct, but we have seen occasional inconsistencies in staging where pageCount appears to be one less than expected when the last page is partially full. We are using the Python SDK genesyscloud_analytics.get_analytics_users_summary(). Any insights on the most reliable way to handle this pagination logic would be appreciated.