We are building a custom New Relic dashboard to track agent efficiency in real-time. The goal is to ingest agent utilization metrics-specifically tHandle, tAcw, and tHold-and break them down into 30-minute intervals.
I’m using the Reporting API (/api/v2/analytics/reporting/query) because the standard analytics dashboard doesn’t export the raw data in the format we need for NRQL aggregation.
Here is the JSON payload I’m sending:
{
"queryType": "real-time",
"interval": "30m",
"metricFilters": [
{
"id": "tHandle",
"filter": "sum"
},
{
"id": "tAcw",
"filter": "sum"
},
{
"id": "tHold",
"filter": "sum"
}
],
"groupBy": [
"agent.id",
"interval"
],
"timeFilter": {
"from": "2023-10-27T12:00:00.000Z",
"to": "2023-10-27T13:00:00.000Z"
}
}
The API returns a 200 OK, but the results are weird. The interval field in the response doesn’t seem to align with the 30-minute buckets I requested. It looks like it’s defaulting to hourly or just giving me a single aggregate for the whole hour.
Also, when I try to add tHold to the metricFilters, the API throws a 400 Bad Request saying the metric is not available for real-time query type.
Is tHold only available in historical queries? And how do I force the 30-minute granularity in the response? The documentation mentions interval parameter but I’m not seeing the breakdown in the JSON response.
Are you hitting the 413 error again? The interval size might be causing payload bloat. Try splitting the query into smaller chunks or using the WFM analytics endpoint instead. It handles adherence data better.
The point above is correct about the 413 errors when you push too much data in one go, but splitting queries manually is a pain to maintain. The real issue here is usually how the intervalSize interacts with the groupBy fields. If you’re asking for 30-minute intervals on a large date range, the API tries to return a massive grid that exceeds the payload limit.
You don’t necessarily need WFM endpoints for basic handle/ACW time. The standard analytics API works fine if you structure the request correctly. You should use intervalSize of PT30M and ensure you’re grouping by time and userId (or queueId depending on your view). The key is to paginate through the results using the nextPageToken if the response indicates more data exists, rather than trying to fetch everything at once.
Here is a cleaner Python snippet using the SDK to handle this properly. It fetches the data in chunks, which avoids the bloat issue entirely:
from genesyscloud.reporting import ReportingApi
from genesyscloud.reporting.models import QueryBody, QueryDefinition
def get_agent_utilization(platform_client, start_date, end_date):
reporting_api = ReportingApi(platform_client)
query_definition = QueryDefinition(
query_type='utilization',
interval_size='PT30M',
group_by=['time', 'userId'],
select=['tHandle', 'tAcw', 'tHold']
)
query_body = QueryBody(
date_from=start_date,
date_to=end_date,
query=query_definition
)
# Initial call
response, status_code, headers = reporting_api.post_analytics_reporting_query(body=query_body)
if status_code == 200:
for row in response.summary:
print(f"User: {row.userId}, Handle: {row.tHandle}, ACW: {row.tAcw}")
# Handle pagination if needed
while response.next_page_token:
query_body.next_page_token = response.next_page_token
response, status_code, headers = reporting_api.post_analytics_reporting_query(body=query_body)
# Process next batch...
else:
print(f"Error: {status_code}, {response}")
Make sure your OAuth token has the analytics:report:view scope. If you’re still seeing issues, check the x-gc-request-id header for validation errors. The payload structure is strict.