Analytics API 413 on 90-day query window

Running into a wall with the Analytics API. We need to pull conversation details for the last quarter to feed the custom desktop app, but the endpoint keeps rejecting the payload.

The request hits GET /api/v2/analytics/conversations/details/query. The body looks like this:

{
 "dateFrom": "2023-10-01T00:00:00.000Z",
 "dateTo": "2023-12-31T23:59:59.999Z",
 "select": ["conversationId", "startTime", "duration"],
 "size": 500
}

Getting a straight 413 Entity Too Large response. The error body says the request exceeds the maximum allowed size.

My thought process here is that the query engine is pre-calculating the result set size based on the date range before it even hits the pagination layer. A 90-day window with high volume is obviously going to blow past whatever limit is in place.

I’ve tried breaking this down using the SDK. The logic looks something like this in the client code:

val analyticsApi = AnalyticsApi()
var currentFrom = startDate
while (currentFrom <= endDate) {
 val dateTo = minOf(currentFrom.plusDays(7), endDate)
 val query = AnalyticsQueryBody()
 .dateFrom(currentFrom)
 .dateTo(dateTo)
 .select(listOf("conversationId"))
 
 val response = analyticsApi.postAnalyticsConversationsDetailsQuery(query)
 // process response
 currentFrom = dateTo.plusDays(1)
}

The split approach works for smaller chunks, but I’m losing track of the pagination cursor across the date boundaries. The nextPageUri seems to reset or invalidate when I change the date parameters for the next loop iteration.

The docs mention splitting queries but don’t give a concrete example on how to chain the pagination tokens safely across multiple date windows.

The 413 error doesn’t give a specific byte count or row limit. Just the generic message. Makes debugging this a bit of a shot in the dark.

You’re hitting the 413 because the Analytics API doesn’t like big date ranges in a single POST request. It’s not just about the payload size, it’s about how the backend processes the query. The default timeout kicks in before it can aggregate 90 days of conversation details.

Break it down into smaller chunks. I usually do 7-day windows. It’s more requests, but they actually complete. Here’s how you’d structure it in the SDK to avoid the crash:

const analyticsApi = platformClient.analyticsApi;
const startDate = new Date("2023-10-01T00:00:00.000Z");
const endDate = new Date("2023-12-31T23:59:59.999Z");
const batchSize = 7; // days

const results = [];

let currentStart = new Date(startDate);
while (currentStart < endDate) {
 let currentEnd = new Date(currentStart);
 currentEnd.setDate(currentEnd.getDate() + batchSize);
 
 // Don't overshoot the final date
 if (currentEnd > endDate) {
 currentEnd = new Date(endDate);
 }

 const body = {
 dateFrom: currentStart.toISOString(),
 dateTo: currentEnd.toISOString(),
 select: ["conversationId", "startTime", "duration"],
 size: 1000 // Max per page
 };

 try {
 const response = await analyticsApi.postAnalyticsConversationsDetailsQuery(body);
 results.push(...response.entities);
 
 // Handle pagination if needed for the batch
 // while (response.nextPageUri) { ... }
 
 } catch (err) {
 console.error(`Failed batch ${currentStart.toISOString()}:`, err);
 }

 currentStart = new Date(currentEnd);
}

Also check if you’re hitting the rate limit on the analytics endpoint. It’s stricter than the general API. Add a small delay between batches if you see 429s. The query engine gets hammered by large date spans so it throttles aggressively.