Hi Mike - This is a known behavior difference in Genesys Cloud when moving from chat to web messaging. Here's what those GUIDs represent:
What the GUIDs Are
addressTo - This is the conversation ID or the messaging deployment ID / flow ID on the Genesys side.
addressFrom - This is the guest participant's anonymous session ID (the web messaging SDK generates this for the end user).
In web messaging, unlike traditional chat or voice, there's no real phone number, email, or named endpoint - the communication is between anonymous browser sessions and Genesys flows, so the platform uses internal UUIDs.
Why This Happens
Chat uses identifiable addresses (e.g., display names, chat usernames), so addressTo/addressFrom return human-readable values.
Web Messaging uses the Messenger SDK which creates anonymous sessions identified by GUIDs. This is by design, not a bug.
How to Resolve the GUIDs to Useful Info
1. Get Conversation Details
GET /api/v2/conversations/messages/{conversationId}
Copy
This returns participant details including the agent name, queue, and customer attributes.
2. Get External Contact Info (if captured)
If your web messaging flow captures customer identity (e.g., via authenticated messaging or pre-chat form), you can look up:
GET /api/v2/conversations/{conversationId}/participants
Copy
3. In Your EventBridge Processing
When you receive the ACW event, use the conversationId from the event payload to call the Conversations API and enrich the record:
# Pseudocode for enriching the event
conversation_id = event["detail"]["conversationId"]
# Call Genesys API to get full participant details
response = get_conversation(conversation_id)
agent_name = response["participants"][0]["name"]
customer_info = response["participants"][1]["attributes"]
python
4. Authenticated Web Messaging
If you need consistent customer identity, consider enabling Authenticated Web Messaging - this ties sessions to known users and provides richer participant data in events.
Summary
Media Type addressTo / addressFrom Behavior
Voice Phone numbers Human-readable
Chat Display names Human-readable
Email Email addresses Human-readable
Web Messaging GUIDs By design (anonymous sessions)
This isn't a bug - it's an architectural difference in how web messaging handles identity. The workaround is to enrich your EventBridge events by calling back into the Conversations API using the conversation ID to get meaningful participant details from Genesys perspective and someone from community might add more to this.
------------------------------
Raja Sridhar Nagella
Sr Lead Software Engineer [Architect, Design, Build, Support – ADP - Contact Center Engineering]
------------------------------
Original Message:
Sent: 04-16-2025 23:00
From: Mike Hardie
Subject: Event Bridge Notification
Hi, we have event bridge notification active for capturing agent's ACW (pre triggers)
A client is currently changing from chat to web messaging.
When an ACW event is generated from a web message ACW it includes the following two fields
"addressTo": "7e20658d-1994-4029-8936-78bccf9edb30",
"addressFrom": "33f61f72-d8b9-4007-a2b9-2b9039802ff6",
Can anyone tell me what these GUID's are pointed to so I can try and get real info - other media provide human values rather than GUIDs
Or is this bug?
Mike
#Integrations
------------------------------
Mike Hardie
Developer
------------------------------