Sending proactive web messaging notifications via /api/v2/conversations/messaging/messages

Hit a 409 Conflict when trying to send a proactive web messaging notification to a guest who closed their session 20 minutes ago. I’m attempting to push a message using the outbound messaging conversation endpoint, but the API rejects it since the session is technically closed. Need to know if there’s a specific header or endpoint to push a proactive notification to an existing guest ID without reopening the conversation.

1 Like

Cause:
You can’t shove a message into a dead session. Genesys Cloud locks the conversation once the status hits closed or ended. That 409 Conflict isn’t a bug, it’s the platform protecting data integrity. Trying to reuse the old conversationId is like trying to mail a letter to a house that got demolished. The participantId might still exist in the database, but the channel connection is severed. You’ll need to spin up a fresh conversation context if you want to reach that guest again.

Solution:
Skip the update endpoint entirely. Instead, kick off a new outbound web messaging session using the Guest API. You’ll need the guest’s contactId (usually stored as the externalContactId in their participant record from the last chat). Here’s the flow:

  1. Get the guest’s contact ID from the previous conversation’s participant list.
  2. POST to /api/v2/conversations/messages with a new conversation ID (leave it blank or let the API generate one) but include the contactId in the payload.
POST /api/v2/conversations/messages
{
 "contactId": "guest-uuid-from-previous-session",
 "type": "message",
 "text": "Hey there! We noticed you left. Need more help?",
 "from": {
 "id": "your-bot-or-agent-id"
 }
}

This creates a brand new conversation thread linked to that same guest profile. It won’t reopen the old chat, but it will pop a notification in their browser if the widget is still active and cookies are intact. Just remember to check the guestAttributes to ensure they haven’t opted out of proactive messages.