Trying to implement typing indicators via the Web Messaging Guest API. The docs for POST /api/v2/webmessaging/guests/messages show a typingIndicator field in the payload, but sending it returns a 200 OK without any effect on the agent side. Checked the network tab, the message arrives, but no typing bubble.
Found an old forum post suggesting a separate PATCH endpoint for status updates, but that endpoint doesn’t exist in the current OpenAPI spec.
Here’s the payload I’m sending:
{
"channelId": "abc-123",
"type": "text",
"content": "",
"typingIndicator": true
}
The response is just { "id": "msg-456", "status": "delivered" }. No error, but no indicator.
Is the typingIndicator field deprecated? Or is there a different mechanism for sending these events in the current Guest API? The SDK wrapper sendTypingIndicator() throws a NotFoundError for the underlying route.
Looking for the correct endpoint or payload structure. The current approach isn’t working.
The typingIndicator field in the message payload is for server-side tracking, not real-time UI signaling. It won’t trigger the bubble. You need to push state changes via the WebSocket connection, not HTTP REST.
If you’re building a custom client, subscribe to the guest’s WebSocket endpoint. Send a JSON payload with type: "typing" to the socket.
// Example payload sent via WebSocket
{
"type": "typing",
"data": {
"isTyping": true
}
}
Studio doesn’t expose a REST endpoint for this because typing states are ephemeral and high-frequency. REST adds too much latency. The widget handles this automatically under the hood using the same socket mechanism.
If you’re stuck on REST, you’re fighting the architecture. Switch to WebSockets for any real-time interaction. The Guest API docs for WebSockets are sparse, but the message structure mirrors the REST payload minus the id field.
Check the connection object in your guest creation response. That’s your socket URL.
Are you hitting the REST API directly with a bearer token, or are you using the genesys-cloud-webmessaging-sdk? The WebSocket suggestion above is correct for the client-side SDK, but if you are building a backend service that needs to simulate typing for a guest (e.g. for a bot or integration), you can’t use PATCH. The docs state: “The typingIndicator field is informational only.” This means it logs the state but does not push a real-time event to the agent UI.
You need to use the Conversation API to update the participant’s status. This requires the conversation:write scope. You’ll get a 405 if you try to PATCH the message endpoint, but a POST to the conversation participants endpoint works.
Here is the actual working curl command to trigger the typing indicator for a specific participant in a conversation:
curl -X POST "https://api.mypurecloud.com/api/v2/conversations/{conversationId}/participants/{participantId}" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer {access_token}" \
-d '{
"routing": {
"priority": 0
},
"state": "typing"
}'
Note that state needs to be typing. If you set it to connected or closed, it won’t show the bubble. Also, ensure your OAuth token has the webmessaging:guest:write scope if you are acting as the guest, or conversation:write if you are a service account. The REST API is strictly for state changes, not real-time streaming. That’s why the SDK uses WebSockets for the live UI updates. If you are mixing REST and WebSocket clients, make sure the participant ID matches exactly. Mismatched IDs cause silent failures.