Analytics API 413 Entity Too Large on 90-day query

Just noticed that my Python script crashes when pulling interaction data for a full quarter. The SDK doesn’t seem to chunk the request automatically.

from purecloudplatformclientv2 import AnalyticsApi, AnalyticsInteractionsQuery

analytics = AnalyticsApi(client)
query = AnalyticsInteractionsQuery()
query.date_from = '2023-10-01T00:00:00.000Z'
query.date_to = '2023-12-31T23:59:59.999Z'
query.entity_id = 'my-bot-id'

try:
 result = analytics.post_analytics_interactions_query(body=query)
except Exception as e:
 print(e)```

I get a `413 Entity Too Large` response immediately. The docs mention pagination for results, but not for the query scope itself. I'm using `v2.18.0` on Windows. How do I split this? Do I need to loop through monthly ranges manually? 

`for month in range(10, 13): ...`

Is there a cleaner way or am I forced to write the splitter logic? The batch size limit feels arbitrary for a standard quarterly report.

It’s worth reviewing at breaking that 90-day window into smaller chunks. The Analytics API has hard limits on request payload size, and a single query spanning a quarter easily hits the 413 Entity Too Large error. The SDK won’t handle this pagination for you automatically, so you need to manage the date ranges manually.

Here is a TypeScript snippet showing how to iterate through 30-day windows. This pattern works regardless of whether you are using Python or the Pulumi SDK for provisioning, but the logic for the API call remains the same.

const start = new Date('2023-10-01T00:00:00.000Z');
const end = new Date('2023-12-31T23:59:59.999Z');
const chunkSize = 30 * 24 * 60 * 60 * 1000; // 30 days in ms

let currentStart = start;
while (currentStart < end) {
 let currentEnd = new Date(currentStart.getTime() + chunkSize);
 if (currentEnd > end) currentEnd = end;

 const query: AnalyticsInteractionsQuery = {
 dateFrom: currentStart.toISOString(),
 toDate: currentEnd.toISOString(),
 entityId: 'my-bot-id',
 groupBy: ['wrapupCode'] // Adjust groupBy as needed
 };

 try {
 const result = await analyticsApi.postAnalyticsInteractionsQuery({ analyticsInteractionsQuery: query });
 console.log(`Processed chunk: ${currentStart.toISOString()} to ${currentEnd.toISOString()}`);
 // Handle result.body here
 } catch (error) {
 console.error('Chunk failed:', error);
 }

 currentStart = currentEnd;
}

Be careful with the dateTo field. It is inclusive, so overlapping windows can cause duplicate data if you are aggregating results locally. Ensure your aggregation logic handles unique interaction IDs.

I run similar patterns in my Pulumi stacks when validating analytics data against provisioned queue configurations. It keeps the CI/CD pipeline stable and avoids those nasty 413 errors that break builds. If you are hitting rate limits too, add a small delay between chunks. The Genesys Cloud platform is strict on burst traffic.

Ah, this is a recognized issue where the raw payload exceeds the gateway’s limit, so you must split the date range into smaller chunks like 7-day intervals before sending the request. The Java SDK provides utility methods to calculate these windows, ensuring each POST to /api/v2/analytics/conversations/interactions/query stays under the threshold. Here is how I structure the date iteration in my MuleSoft orchestration layer to avoid the 413 error entirely:

LocalDate start = LocalDate.of(2023, 10, 1);
LocalDate end = LocalDate.of(2023, 12, 31);
while (start.isBefore(end)) {
 LocalDate chunkEnd = start.plusDays(6); // 7-day window inclusive
 if (chunkEnd.isAfter(end)) chunkEnd = end;
 
 AnalyticsInteractionsQuery query = new AnalyticsInteractionsQuery();
 query.setDateFrom(OffsetDateTime.ofInstant(chunkStart.atStartOfDay(ZoneOffset.UTC).toInstant(), ZoneId.systemDefault()));
 query.setDateTo(OffsetDateTime.ofInstant(chunkEnd.plusDays(1).atStartOfDay(ZoneOffset.UTC).toInstant(), ZoneId.systemDefault()));
 // execute query and aggregate results
 start = chunkEnd.plusDays(1);
}

The chunking strategy is correct. You must split the 90-day range manually.

1. Create 7-day windows.
2. Iterate with Promise.all.

const chunks = [];
for (let i = 0; i < 90; i += 7) {
 chunks.push(queryRange(i, i + 7));
}
await Promise.all(chunks);

My Svelte widget uses this pattern. It avoids the 413 error completely.

If I recall correctly, the 413 error triggers because the JSON payload for the date range exceeds the gateway limit. You must manually split the query into smaller windows to bypass this restriction.

1. Divide the 90-day period into 7-day chunks.
2. Iterate through each window with the SDK.

from datetime import datetime, timedelta

start = datetime(2023, 10, 1)
end = datetime(2023, 12, 31)

while start < end:
 chunk_end = min(start + timedelta(days=7), end)
 # Execute query for start to chunk_end
 start = chunk_end

This prevents the payload size from hitting the threshold. I use this pattern for audit log extraction to ensure consistent data ingestion.