Just noticed that my aggregation query to /api/v2/analytics/conversations/details/query returns empty results when I attempt to group by both queue.name and mediaType simultaneously. I am constructing the JSON payload with groupBy set to ["queue.name", "mediaType"] and specifying a standard interval, but the response body is consistently empty despite valid data existing for the selected time range.
Here is the minimal payload structure I am sending via POST:
Is there a specific limitation on combining these dimensions in the groupBy array, or am I missing a required clause in the filter definition that forces the aggregation to resolve correctly?
This is caused by scope mismatch in your query definition. The analytics engine requires explicit entity identifiers when grouping by hierarchical attributes like queues. You cannot rely on implicit context if you want cross-media aggregation.
Define the entityId in the groupBy objects, not just the path.
Ensure your time interval does not exceed the default limit without pagination.
Verify that the interval aligns with your data retention policy.
entityId must map to the actual dimension key. If you omit the selectionCriteria, the engine defaults to a single media type, causing empty sets for the other. Check your OAuth scope; analytics:query:read is mandatory. I see this error constantly when developers copy-paste generic examples without adjusting for specific WFM or routing contexts.
To fix this easily, this is… stop guessing the groupBy keys. The API is strict. Use the exact metric definition from the schema. Also, ensure your IAM policy in Pulumi grants analytics:report:view on the specific queue ARNs, or the query will silently fail.
You need to add queue.id to your groupBy array. The analytics engine requires the entity ID for deterministic bucketing when grouping by name. Without it, the query fails to resolve the hierarchy correctly.
I see this often when building Datadog dashboards from GC metrics. The API documentation implies name-only grouping works, but the underlying SQL engine needs the unique identifier to avoid ambiguity. Try this payload structure:
If you check the docs, they mention that grouping by queue.name and mediaType simultaneously is valid, but it silently drops results if the query exceeds the maximum number of unique buckets allowed in a single response. When migrating complex Five9 reports, I found that the analytics engine often returns empty arrays not because of scope issues, but because the combination of queues and media types creates too many distinct groupings for the default pagination limit.
Try reducing the time interval to a single day and explicitly setting the size parameter to the maximum allowed (usually 1000). If you still get empty results, check if any of the queues in your filter are inactive. The API excludes inactive entities by default unless you specify entityType filters carefully. Also, ensure you are using the correct OAuth scope: analytics:report:view is mandatory, but if you are querying across multiple organizations, you might need analytics:report:query as well.
Here is a working curl example that isolates the issue by limiting the scope to a single queue and media type first: