Looking for advice on why wrapUpCode keeps coming back null in our Spring Boot analytics service. we’re hitting /api/v2/analytics/details with the Java SDK. the docs say "wrapUpCode is populated for agent wrap-up intervals", but the response just shows "wrapUpCode": null. we checked the date range and added wrapUpCode to the metrics array.
not sure if it’s a known limitation or a query syntax mess up.
Make sure you are requesting the wrap_up_code metric explicitly in your query body. the default metric set for details queries often omits this specific attribute, which results in null values even when agents are actually wrapping up. check the documentation for the wrap_up_code metric definition to ensure the name matches exactly.
also verify that the time bucket size is appropriate. if you are using a large interval like 1 hour, the aggregate data might not resolve individual wrap-up codes correctly. try reducing the interval to 15 minutes or less. this forces the system to calculate the metric at a granular level where wrap-up states are more distinct and less likely to be averaged out or dropped.
lastly, confirm the agent status during the wrap-up period. if agents are transitioning directly from after-call-work to available without a distinct wrap-up state in the routing configuration, the code might not populate. check the interaction lifecycle settings in admin to ensure wrap-up is enabled and mapped to a specific code.
Make sure you’re actually looking at the right metric name in the payload. wrapUpCode is the response field, but the query metric is wrap_up_code. if you’re just copying the response key into the request body, it’ll silently fail to populate.
also, the details endpoint is finicky with interval types. if you’re using INTERVAL type, you need to ensure the groupBy array includes wrap_up_code alongside your primary dimension (usually agent_id or wrap_up_code itself). without it, the engine aggregates the data but drops the code value to save payload size.
here’s the exact JSON structure that works for me in the Java SDK CreateDetailsQueryRequest:
{
"dateFrom": "2023-10-01T00:00:00Z",
"dateTo": "2023-10-02T00:00:00Z",
"type": "INTERVAL",
"groupBy": ["wrap_up_code"],
"metrics": ["wrap_up_code", "handle_time"],
"filter": [
{
"dimension": "queue_id",
"type": "EQUALS",
"value": "your-queue-id-here"
}
]
}
one thing to watch out for is the wrap_up_code dimension filter. if you don’t filter by a specific queue or group, the query might return empty buckets for agents who didn’t wrap up, which looks like nulls. i usually add a filter for wrap_up_code not equals null in the filter array to strip out the noise, though that depends on whether you want to see the agents who skipped it.
also check if your agents are actually setting a code. in Architect, if the wrap-up form is optional or hidden, the API won’t invent a value. it stays null. i’ve seen this happen when migrating from Twilio because the old system forced a reason code, but GC defaults to optional unless you configure the wrap-up form strictly.
check the wrap_up_code metric definition in the docs again. it’s easy to miss the nuance about INTERVAL vs SUMMARY types. SUMMARY gives you the count per code, INTERVAL gives you the timeline. if you want the specific code per agent interaction, INTERVAL with groupBy: ["agent_id", "wrap_up_code"] is the way to go.
yep, the snake_case vs camelCase trip up is real. the sdk maps wrap_up_code to the request, but the json response gives you wrapUpCode. make sure your java model has the correct @JsonProperty annotation if you’re deserializing manually. also, double check that the agent actually selected a wrap-up code in the ui, otherwise the metric stays null regardless of the query.
the snake_case vs camelCase issue is definitely the culprit here. i see this all the time with the Java SDK. it handles the mapping, but only if your request body is structured exactly right.
groupBy array. if you’re querying wrap_up_code, it must be in there. otherwise the engine aggregates everything into a single bucket and drops the nulls.wrap_up_code in the request, not wrapUpCode.here’s a quick python snippet to show the structure. same logic applies to Java:
query = {
"view": "agent_interactions",
"groupBy": ["wrap_up_code"],
"metrics": ["wrap_up_code"]
}
if you don’t group by it, the detail query returns the interval, not the code. also, make sure the agents are actually using wrap-up codes. if they’re just ending calls without selecting one, the metric stays null. no amount of API tweaking will fix bad user behavior. check your WFM config too.