The /api/v2/analytics/conversations/agents/query endpoint is notoriously rigid with its interval definitions. You can’t just pass a custom string like “PT30M” and expect it to work for agent-level metrics. The API validates the interval against a strict set of predefined buckets. For sub-daily granularity, you’re usually stuck with PT1H or PT4H depending on the metric type and your org’s data retention policies. tHandle and tAcw are often aggregated at a coarser level to protect privacy and reduce load.
If you need 30-minute slices, you’ll have to query at PT1H and then split the data client-side, or accept the hourly granularity. Here’s the correct payload structure for an hourly query. Note the interval value must be PT1H.
{
"dateFrom": "2023-10-27T00:00:00.000Z",
"dateTo": "2023-10-27T23:59:59.999Z",
"interval": "PT1H",
"groupBy": ["user"],
"select": ["tHandle", "tAcw", "tReady", "tWrapup"],
"filters": {
"type": {
"path": "user",
"operator": "in",
"values": ["user-id-1", "user-id-2"]
}
}
}
Don’t forget the scope analytics:conversation:view. If you hit a 400 error, check the dateFrom and dateTo alignment with the interval. The start time must align with the hour boundary if you use PT1H. If you try to start at 10:30, it’ll reject the request.
Also, keep in mind that agent analytics data has a delay. It’s not real-time. You’re usually looking at data that’s 15-30 minutes old. If you’re feeding this into New Relic, make sure your ingestion pipeline accounts for that lag. Otherwise, your dashboards will show gaps or duplicate data when the late batches arrive.
There’s no direct API support for PT30M on this specific endpoint. You’ll have to roll your own aggregation logic. Take the hourly response, split each hour into two 30-minute blocks, and average the metrics. It’s not perfect, but it’s the only way to get closer to what you want without waiting for NICE to expand the interval options.