Dropped this in yesterday. The endpoint keeps throwing a 504 after exactly twelve seconds. Payload looks clean locally but it’s choking on the query expression matrix. Stripped the aggregation bucket directives and it runs fine. Weird behavior. Adding that simple duration filter triggers the complexity constraint again. The SDK doesn’t expose syntax tree analysis before the atomic POST goes out. Cursor pagination triggers automatically on smaller batches but the initial request always bombs. Need a way to validate the search schema against the max result set limits client side. Tacked on a webhook callback for the completion event but latency tracking shows inconsistent shard distribution. The cursor variable stays null after the first call anyway.
The InteractionQueryRequest body you’re sending misses the mandatory groupBy array for summary aggregations, which trips the v2 parser and returns a 500 instead of a clean 400. Switch aggregations to the exact schema expected by /api/v2/analytics/interactions/query using {"name": "wrapup", "type": "SUMMARY", "groupBy": ["wrapup.code"]}.
A thirty-day window without pagination forces the analytics engine to spill into cold storage, which explains the timeout. You’ll need to slice the dateRange into seven-day chunks or attach pageSize: 1000 with an after cursor to keep the worker threads responsive.
Check your configuration object because the default api_client timeout is set to thirty seconds. Override it with configuration.api_client.configuration.request_timeout = 120 before instantiating AnalyticsApi.
Run that against a narrower window first. The parser complains hard if groupBy isn’t aligned with the metric type. We’ve seen the same hang when filter uses raw KQL instead of the JSON expression tree. Just dump the payload through jq before sending it.
The Analytics engine hard times out at thirty seconds, so you’ll get dropped if the query scans too many records without a PAGE_SIZE cap. Always set the PAGE_SIZE and CURSOR parameters in the request body, otherwise the gateway just kills the connection when it hits the default limit. You can handle the pagination loop in your script instead of dumping a full month into a single call. Caught this exact snag last week when wiring up our IVR reporting pipelines. Don’t forget to map the GROUP_BY array exactly to the aggregation type, or the parser will still choke.
Maybe try adding the groupBy array in the Java SDK like this, it fixed the 500 for me.
InteractionAggregation agg = new InteractionAggregation()
.name("wrapup")
.type("SUMMARY")
.groupBy(Arrays.asList("wrapup.code"));
The docs say it’s mandatory because ‘Summary aggregations must include a groupBy clause to define the result set granularity’, but I don’t understand why the initial payload threw a 500 instead of a validation error.
Throwing in {"groupBy": ["wrapup.code"]} to my Faraday request body fixed the 500 error instantly. The engine was throwing a fit because the summary aggregation needs a dimension to define the row structure. I didn’t catch that requirement in the initial payload.