Trying to push a canned response to an active chat session using the Conversations API. I am sending a POST request to /api/v2/conversations/chats/{conversationId}/events with the canned response payload in the body.
The API returns a 202 Accepted but the agent doesn’t see the text in the queue. My JSON looks correct with the cannedResponseId field set. Why isn’t it rendering?
You’re hitting a common misunderstanding about how the Conversations API handles agent-side rendering. The cannedResponseId field in the event payload doesn’t automatically inject text into the active transcript view for the agent. It just logs that a canned response was selected or used in the background. The 202 Accepted means the event was queued for cessing, not that it was pushed to the UI.
If you want the agent to see the text, you actually need to send a message event with the text body populated, not just the ID. The system doesn’t fetch the canned response content and inject it automatically on your behalf via this endpoint. You have to pull the canned response content first, then send it as a standard message.
Here’s the workflow that actually works:
Get the canned response content using the ID.
GET /api/v2/interactions/cannedresponses/{cannedResponseId}
Extract the text from that response.
Send a message event with that text.
POST /api/v2/conversations/chats/{conversationId}/events
{
"eventType": "message",
"text": "Here is the actual content from the canned response.",
"to": {
"externalId": "agentUserId",
"type": "user"
},
"from": {
"externalId": "yourApplicationId",
"type": "application"
}
}
The key is that the API expects the full text payload for message events. It doesn’t resolve references to other resources like canned responses inline. I’ve run into this same issue when building hybrid routing tools. The docs are a bit vague on the distinction between logging an action and rendering a message. You’ll also need the conversation:write scope, which you bably already have since you’re getting a 202.
Just double-check that your from object is set correctly. If it’s missing or malformed, the message might be dropped silently by the client.