I’m hitting a wall with the Genesys Cloud Analytics API. We need to pull interaction metrics for a 90-day window to feed into our New Relic dashboards. The standard query works fine for 30 days, but extending it to 90 days throws a 413 Entity Too Large error.
Here’s the request body I’m sending to POST /api/v2/analytics/interactions/queries:
{
"dateFrom": "2023-10-01T00:00:00.000Z",
"dateTo": "2023-12-30T23:59:59.999Z",
"groupBy": ["routingQueue.id"],
"interval": "PT1H",
"metrics": {
"durationWrapUp": {},
"talkDuration": {}
}
}
The error response is generic:
{
"errors": [
{
"code": "tooLarge",
"message": "Request entity too large"
}
]
}
I’ve tried reducing the interval to PT4H and even PT1D, but the 413 persists. I assumed the payload size was the issue, but the JSON is tiny. Is this a server-side limit on the result set size or the query complexity?
My plan is to split this into three 30-day chunks in our Python script and aggregate the results locally before sending to New Relic. Is that the only option, or is there a way to paginate or stream this data? I need to make sure the aggregation logic handles the time buckets correctly.
You’re hitting the payload size limit because the API expects the query to be sent as a form-encoded body or a compressed stream, not just raw JSON in the header or a massive uncompressed body. For 90-day spans, the resulting dataset is huge, and the request body itself isn’t the issue-it’s usually how you’re sending it or the lack of compression.
First, check if you’re using the application/json content type without compression. The Genesys Cloud platform handles large queries much better when you use gzip compression. Here’s how you’d structure that with curl:
curl -X POST "https://api.mypurecloud.com/api/v2/analytics/interactions/queries" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Content-Encoding: gzip" \
--compressed \
-d @query.json.gz
If you’re using the SDK (like Python or Node), ensure you’re not accidentally buffering the entire response into memory before processing. The 413 error can sometimes be misleading if your client library is trying to send a malformed or overly verbose request body.
Also, consider splitting the query. Instead of one 90-day block, break it into three 30-day chunks. This reduces the load on each request and makes it easier to handle retries if one chunk fails. You can parallelize these requests to get the data faster.
// Split into multiple smaller queries
[
{ "dateFrom": "2023-10-01T00:00:00.000Z", "dateTo": "2023-10-31T23:59:59.999Z" },
{ "dateFrom": "2023-11-01T00:00:00.000Z", "dateTo": "2023-11-30T23:59:59.999Z" },
{ "dateFrom": "2023-12-01T00:00:00.000Z", "dateTo": "2023-12-30T23:59:59.999Z" }
]
This approach is more reliable and avoids hitting the entity size limits. Just make sure your downstream New Relic ingestion can handle the increased frequency of smaller payloads.