Trying to pull screen recording metadata for the compliance team but the python script is failing on the filter payload. Sorry for this dumb question, the date format is probably wrong because the endpoint returns a 400 error when passing the range object. Some posts say the screen recording api is deprecated but that is not true for our org on version 2.11.
{
"filter": {
"dateRange": {
"start": "2023-10-01T00:00:00+09:00",
"end": 2023-10-01T23:59:59+09:00"
}
}
}
The console is showing invalid_filter_syntax and the sdk docs don’t list the right keys for wem recordings.
The filter object structure you’re passing doesn’t match what /api/v2/recordings/screens expects. That endpoint doesn’t parse a nested JSON payload for date boundaries. You’ll need to flatten the entire block into a single filter query parameter using the dateRange operator syntax. The backend parser chokes on the nested start and end keys because it’s looking for a colon-separated string instead. You can also drop the timezone offset entirely. Genesys Cloud normalizes everything to UTC anyway, so swapping +09:00 for a trailing Z usually clears the validation error. Parser usually chokes on that. Happens more than you’d think.
Switching to query parameters bypasses the JSON serialization issue completely. Here’s how the request should look when you pass the string through the params dictionary instead of a data payload.
import requests
headers = {
"Authorization": "Bearer YOUR_ACCESS_TOKEN",
"Accept": "application/json"
}
params = {
"filter": "dateRange:2023-10-01T00:00:00.000Z/2023-10-31T23:59:59.999Z",
"pageSize": 50
}
response = requests.get(
"https://api.mypurecloud.com/api/v2/recordings/screens",
headers=headers,
params=params
)
print(response.status_code, response.json())
The requests library handles URL encoding automatically when you use params, which saves you from manually escaping the colon in dateRange:. If you’re still getting a 400, check the X-Request-Id header in the response payload. That value maps directly to the server logs. I’ve seen the backend reject ISO strings that lack the .000Z millisecond precision, so adding that suffix fixes half of these filter errors. You might also want to chain mediaType:screen into the same filter string to tighten up the result set. The API supports multiple operators separated by spaces, so dateRange:2023-10-01T00:00:00.000Z/2023-10-31T23:59:59.999Z mediaType:screen works fine.
Just make sure your OAuth token includes the view:screenrecordings scope. Missing scopes usually return a 403, but the Python SDK sometimes masks that as a 400 if the initial handshake fails. You’ll want to verify the token payload before debugging the filter string further. Sometimes the millisecond precision gets stripped during serialization anyway.