Running the historical ETL pipeline against /api/v2/analytics/conversations/details/queries and the pagination chain just snaps after the first batch. Tenant has the compliance data masking feature enabled for PII redaction. First request pulls back exactly 1000 records in standard JSON format. The next_page_token comes back clean. Script hands that token to the second request and immediately hits a 403 Forbidden. Error payload just says "error_code": "compliance_access_denied".
Switched the export format to CSV to bypass the JSON schema validation in our data warehouse loader. CSV pulls work fine. Pagination holds up. Problem is the downstream transformation layer expects the nested interactions and wrapup_codes objects. Flattening that CSV manually takes three days of regex work. It’s completely murdering the timestamp alignment for our queue delay metrics.
The documentation mentions rate limits but says nothing about compliance features intercepting the pagination loop. Checked the service account scopes. analytics:conversation:view and analytics:export:view are both active. No recent role changes on the tenant side. Tried dropping the pageSize down to 50. It doesn’t change anything. Token still dies on page two. That approach does jack all for the migration timeline.
Only workaround that keeps the pipeline moving is scheduling the bulk export through the UI and letting it generate the S3 link. Caps us at 24 hours per run though. We’ve got 18 months of historical calls to migrate before the old data lake expires.
[screenshot of the 403 response in Postman]
[screenshot of the compliance masking toggle under Admin > Security > Data Masking]
Logs show the token expiration timestamp matches the request time exactly. Looks like the masking engine is invalidating the session mid-pull.