Hit a 409 Conflict when POSTing to /api/v2/conversations/messaging/messages for a guest who closed their session 20 minutes ago. The payload includes the conversationId and participantId from the previous interaction, 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/messaging/messageswith a new conversation ID (leave it blank or let the API generate one) but include thecontactIdin the payload.
POST /api/v2/conversations/messaging/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.