We’ve got a custom web chat interface built on top of the Genesys Cloud Web Messaging Guest API. Everything works fine for sending text messages and receiving responses. The issue is with the typing indicators.
I’m sending a POST request to /api/v2/conversations/messaging/participants/{participantId}/typing with the following payload:
{
"active": true
}
The request returns a 204 No Content, which suggests it’s accepted. However, the agent on the other side never sees the “User is typing…” status in the Conversations UI. They only see the status update after the actual message is sent via the standard message endpoint.
I’ve checked the event logs. The typing event seems to be firing on our side, but nothing shows up in the agent’s client events or the conversation history. I’ve tried adding a timestamp field to the payload, thinking maybe it needs one, but that just resulted in a 400 Bad Request saying the field is unexpected.
Here’s the relevant snippet from our frontend code:
async function sendTypingIndicator(participantId, active) {
const token = await getAccessToken();
const response = await fetch(`/api/v2/conversations/messaging/participants/${participantId}/typing`, {
method: 'POST',
headers: {
'Authorization': `Bearer ${token}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ active })
});
console.log('Typing indicator status:', response.status);
}
The response.status is consistently 204. Is there a specific requirement for the participant ID? I’m using the ID returned from the initial POST /api/v2/conversations/messaging call.
Also, I noticed the documentation mentions that typing indicators are ephemeral. Does that mean they don’t persist in the API logs, making it harder to debug? I’m assuming the 204 means the server received it, but the agent side isn’t reacting.
Could it be a WebSocket subscription issue on the agent’s client? Or is there a specific header missing from the request? I’ve checked the network tab on the agent’s browser, and I don’t see any incoming WebSocket messages related to typing events when I trigger this from our test client.
Any ideas on what might be blocking the propagation of this state change?