Analytics API Conversation Aggregates query returning 0 records

NICE CXone API & Integrations
1

Can anyone explain why the query returns empty?

  • Using .NET SDK AnalyticsApi.GetAnalyticsConversationAggregatesPost.
  • Payload: interval: "2023-10-01T00:00:00.000Z/2023-10-01T01:00:00.000Z", view: "default".
  • Response: 200 OK with results: [].
  • Verified OAuth token is valid. Checked UI for same interval; data exists. Suspect timezone offset issue in interval string.
2

Check your interval format and timezone alignment, as the Analytics API is notoriously strict about ISO 8601 duration strings and requires UTC timestamps without ambiguity. The empty results: [] response usually indicates that the query syntax is accepted (hence the 200 OK) but no data matches the specific window due to a mismatch in how the SDK serializes the interval or a timezone offset issue where your UI shows local time but the API expects strict UTC. In .NET, ensure you are constructing the QueryConversationAggregatesRequest with explicit UTC properties rather than relying on implicit string parsing, which often drops the ‘Z’ suffix or introduces local offsets. Here is the correct SDK usage pattern to guarantee UTC compliance and proper aggregation grouping:

var request = new QueryConversationAggregatesRequest 
{ 
 Interval = "2023-10-01T00:00:00.000Z/2023-10-01T01:00:00.000Z", 
 View = "default",
 GroupBy = new List<string> { "conversationType" }, // Essential for non-empty results
 PageSize = 25,
 PageNumber = 1
};

// Ensure the client uses UTC context
var response = await analyticsApi.GetAnalyticsConversationAggregatesPost(request);

If the interval is correct, the most common culprit is missing the groupBy field, which can cause the engine to return an empty set if it cannot determine the aggregation scope. Additionally, verify that the OAuth token has the analytics:conversation:read scope; a valid token without specific analytics scopes might authenticate but fail to return data silently in some SDK versions. Also, ensure your Genesys Cloud organization is in the same timezone context as the data generation, or explicitly convert your local time to UTC before sending. If you are still seeing issues, try querying a broader interval like last-24-hours to rule out date boundary exclusions.

3

Have you tried explicitly setting the interval to a 1-hour duration string instead of the slash notation? The .NET SDK sometimes mishandles the range format.

{
 "interval": "2023-10-01T00:00:00.000Z/PT1H",
 "view": "default"
}