Analytics API paging object pageSize behavior causing duplicate records

I can’t seem to figure out why my analytics api call returns duplicate records when i set pageSize to 100 and iterate through pageCount. the documentation implies pageNumber should increment by 1 for each subsequent call, but my python script using the genesys cloud sdk receives overlapping data sets starting from the second page. is there a specific offset calculation i am missing in the paging object structure?

Check your pagination strategy. The pageNumber and pageSize model in Genesys Cloud Analytics APIs is prone to data drift during high-throughput periods. If new records enter the dataset between requests, or if the sort order is not strictly deterministic for ties, you will see duplicates or missing records. This is a known behavior with offset-based pagination.

I recommend switching to cursor-based pagination where available, or implementing a strict time-window filtering approach in your Azure Function consumer. Since I work with .NET, the logic translates directly to Python.

Instead of iterating pageNumber, use the nextPageUri provided in the response object. This token encapsulates the exact offset and sort state.

# Python SDK approach using nextPageUri
def fetch_analytics_data(api_client, query_params):
 all_data = []
 current_params = query_params.copy()
 
 while True:
 response = api_client.analytics_api.post_analytics_conversations_details(
 body=current_params
 )
 
 all_data.extend(response.entities)
 
 # Check if there is a next page
 if response.next_page_uri:
 # Parse the URI to extract params or use the SDK's built-in paging helper
 # If using raw requests, follow the URI directly
 current_params = parse_next_page_uri(response.next_page_uri)
 else:
 break
 
 return all_data

If nextPageUri is not available for your specific endpoint, enforce a strict from and to timestamp range that does not overlap. Ensure your query window is small (e.g., 1 hour) and process each window completely before moving to the next. This eliminates the “moving target” problem.

Also, verify your sort order. If you sort by startTime, ensure you have a secondary sort key like id to handle ties deterministically.

This approach stabilizes the data ingestion into your downstream systems.