For the API check on the previous wrap-up code, the endpoint you want is POST /api/v2/analytics/conversations/details/query. Your request body should filter by the customer ANI using the address dimension, set your interval to the last 5 minutes using ISO 8601 format, order by conversationEnd descending so you always get the most recent completed interaction first, and set pageSize to 1 since you only need the last one. From the response, you pull the wrapUpCode from the participants array where purpose equals agent. Here is a starting point for the request body that you will likely need to tweak based on your specific environment and use case:
**Testing needed**
{
"interval": "2026-05-23T00:00:00.000Z/2026-05-23T00:05:00.000Z",
"order": "desc",
"orderBy": "conversationEnd",
"paging": {
"pageSize": 1,
"pageNumber": 1
},
"segmentFilters": [
{
"type": "and",
"predicates": [
{
"type": "dimension",
"dimension": "address",
"operator": "matches",
"value": "${Flow.customerANI}"
}
]
}
]
}
Note: the interval needs to be dynamic in your actual data action; you would calculate the current time minus 5 minutes and pass it in as a variable rather than hardcoding the date. And as mentioned, this is a starting point, so expect some tweaking.
Make sure your data action handles the empty array case cleanly because if no conversation is found within the window, you want it to return a clear empty string, not throw an error that dead-ends the customer. Default to the normal bot greeting on any failure path.
We use a very similar pattern in our chatbot, where a data action fires at the top of the inbound flow to pull context before the customer even types their first message, and in our preferred agent routing, where a data action queries an external system and branches the flow based on what comes back. Same concept you are applying here, front-load the context check so the routing decision is already made before the customer has to do anything.
For the keyword data table, make sure you store all keywords in lowercase and apply a ToLower() expression on the SMS body before the comparison. Otherwise, you will miss variations like THANKS versus Thanks versus thanks, and your detection will feel inconsistent in production.
The 5-minute window is your most sensitive variable. Worth making it configurable in the data table itself with a column like WindowMinutes, so you can tune it without republishing when requirements change.
One simplification worth considering on step 7, instead of asking the customer if they want a new conversation, flip the default and assume it is a new conversation unless the SMS body matches a keyword. That removes the confirmation step entirely for most customers and only intercepts true closing responses. Cleaner experience and fewer messages in the thread.