Trying to understand why our automated adherence check script is suddenly hitting a wall with the Screen Recording API. We have a custom tool built in Python that pulls screen recording metadata to cross-reference with WFM schedule adherence. It has been running flawlessly for the past six months, but since the last platform update, we are getting a consistent 403 Forbidden response when calling GET /api/v2/analytics/screensessions/{screenSessionId}.
The script runs under a service account that has the analytics:screen-recording:view permission explicitly granted. I have double-checked the role assignments and even tried creating a new service account with the Admin role just to rule out permission creep, but the result is identical. The error payload is minimal, just {"message": "Forbidden", "status": "error"}.
What is particularly strange is that if I use the exact same token in Postman, the call succeeds immediately. This suggests the issue might not be with the token itself, but perhaps with how the script is handling the request headers or the specific user context associated with the screen session. We are based in Central Time (America/Chicago), and the failures started right after our weekly schedule publish on Tuesday morning.
Could there be a new restriction on programmatic access to screen recording data that requires an additional OAuth scope? Or is this a known issue with the analytics endpoints when accessed via non-browser clients? We need this data to validate agent self-service shift swaps against actual logged activity. If we cannot automate this check, our manual review process will lag by days, which is unacceptable for our tight SLA requirements. Any insights from the community on recent changes to the Screen Recording API permissions would be greatly appreciated.