Web Messaging Guest API: Typing indicators not triggering in Architect flow

I’m trying to send typing indicators from our custom web chat widget using the Genesys Cloud Guest API. The messages go through fine, but the typing status never shows up in the Architect flow or the agent desktop. Here is the curl command I’m testing with:

curl -X POST https://api.mypurecloud.com/api/v2/conversations/messaging/conversations/{conversationId}/participants/{participantId}/typing \
 -H 'Authorization: Bearer {token}' \
 -H 'Content-Type: application/json' \
 -d '{"typing": true}'

It returns a 204 No Content, which seems right. But nothing happens on the other end.

  • Using standard OAuth client credentials
  • Conversation ID is valid and active
  • Participant ID is the guest, not the agent

What am I missing?

Looks like you’re hitting a common snag with the Web Messaging API. The endpoint you’re using is correct for signaling, but there are two strict requirements that often get missed. First, the participant ID must be the external ID of the guest, not the internal system ID. Second, the payload needs to explicitly state the typing status.

Here is the corrected curl command. Notice the application/json content type and the specific body structure:

curl -X POST "https://api.mypurecloud.com/api/v2/conversations/messaging/conversations/{conversationId}/participants/{guestExternalId}/typing" \
 -H "Authorization: Bearer {token}" \
 -H "Content-Type: application/json" \
 -d '{
 "typingStatus": "typing"
 }'

If you’re building this in a custom widget using the SDK or direct REST calls, ensure you’re sending this every few seconds while the user is actively typing. The API treats this as a state update, not a persistent flag. If you stop sending it, the indicator clears.

Also, check your Architect flow. The typing indicator won’t trigger any logic unless you have a “Wait for Message” step configured to listen for interaction updates. Sometimes the UI shows it, but the flow doesn’t register the state change if the timeout is too short.

One thing to watch out for: if you’re using the NICE CXone platform, the API path might differ slightly depending on your environment version. The messaging namespace is standard for Genesys Cloud, but CXone uses interactions in some legacy contexts. Double-check your base URL.

If the above doesn’t work, try logging the response body. A 204 No Content means it worked. A 400 or 404 usually points to the wrong participant ID. I’ve seen cases where the external ID has a typo or extra whitespace that breaks the lookup. Trim the ID before sending it.