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.
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:
- Get the guest’s contact ID from the previous conversation’s participant list.
- POST to
/api/v2/conversations/messageswith a new conversation ID (leave it blank or let the API generate one) but include thecontactIdin 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.