Hitting a hard wall with the reporting API. Trying to pull interaction details for a 90-day window to feed a custom dashboard. The endpoint is POST /api/v2/analytics/conversations/details/query.
The payload looks standard:
{
"dateFrom": "2023-10-01T00:00:00.000Z",
"dateTo": "2023-12-30T23:59:59.999Z",
"groupBy": ["interactionType"],
"aggregations": [
{
"name": "Duration",
"type": "SUM"
}
],
"query": {
"type": "AND",
"predicates": [
{
"name": "interactionType",
"operator": "EQUALS",
"value": "voice"
}
]
}
}
Getting a 413 Entity Too Large immediately. Not a timeout. Not a 400. Just 413.
I’ve checked the documentation and the limit is supposed to be on the number of predicates or the granularity, not the date range itself. But the response body is empty.
Tried splitting the date range into three 30-day chunks in the calling script. That works fine. But I need to understand why the single query fails. Is there a hidden limit on the result set size estimate the server calculates before processing?
Here is the curl command for reference:
curl -X POST "https://api.mypurecloud.com/api/v2/analytics/conversations/details/query" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"dateFrom":"2023-10-01T00:00:00.000Z","dateTo":"2023-12-30T23:59:59.999Z","groupBy":["interactionType"],"aggregations":[{"name":"Duration","type":"SUM"}],"query":{"type":"AND","predicates":[{"name":"interactionType","operator":"EQUALS","value":"voice"}]}}'
The 413 error code usually means the request payload is too big. This JSON is tiny. So it must mean the result is predicted to be too big.
How do I paginate or split this without writing a loop in ? The REST Proxy action doesn’t support dynamic date calculation inside the loop easily. I have to hardcode the splits.
Is there a way to get the server to tell me the max safe date range for a given query complexity? Or do I just have to keep shrinking the window until it stops throwing 413?
Also noticed that if I remove the groupBy field, the 90-day query works. So it’s the combination of large date range and aggregation.
This feels like a bug. Or a missing header. I’ve tried adding Accept-Encoding: gzip but no change.
Any ideas on how to handle this in a script without hardcoding 30-day buckets? The business wants a sliding 90-day window. I can’t rebuild the script every month.
The error log just says Request Entity Too Large. No helpful details.
I’m stuck.