We are hitting a hard wall with the Analytics API when trying to pull conversation metrics for a full quarter. The endpoint is returning a 413 Entity Too Large error almost immediately. I am building a custom dashboard using the Embeddable Client App SDK and need to fetch historical data for performance reviews. The documentation mentions paging, but that seems to apply to the response size, not the query body size.
Here is the payload we are sending to /api/v2/analytics/conversations/details/query. We are trying to get data for the last 90 days. The groupBy array is fairly simple, just wrapUpCode and skill.
{
"queryType": "conversations",
"dateRange": {
"startDate": "2023-10-01T00:00:00.000Z",
"endDate": "2023-12-31T23:59:59.999Z"
},
"groupBy": [
"wrapUpCode",
"skill"
],
"filters": {
"type": {
"type": "string",
"filterType": "in",
"values": ["voice", "chat"]
}
},
"select": [
"count",
"handleTime",
"wrapUpTime"
]
}
The error response is straightforward: 413: Request Entity Too Large. It does not give much detail on what exactly is too large. Is it the dateRange span? Or is it the combination of groupBy fields over that long period?
I tried splitting the date range into 30-day chunks. That works, but it feels inefficient. We have to make three separate API calls and then merge the results in the client app. The SDK does not seem to have a built-in method for splitting queries automatically.
We are also using the pageSize parameter, but setting it to 100 or 1000 does not change the 413 error. It seems the issue is with the request body itself, not the response.
Is there a specific limit on the number of days we can query in a single request? The docs are vague on this. They mention performance best practices, but no hard limits. We need a reliable way to fetch this data without hitting this error. Splitting into chunks is our current workaround, but it adds latency to the dashboard load time. Any ideas on how to structure this query better? We are on US/Pacific time, so the timezone conversion is handled on the client side before sending the ISO string. The error happens consistently every time we pass a date range greater than 60 days. It is strange because 60 days works fine. 61 days fails. Is there a hidden threshold?