When calling https://api.usw2.pure.cloud/api/v2/conversations/messages/inbound/open
Is there any identifier that we can add to that call so when we receive the events from the notification API, we can identify to which conversation each messages belongs or is there another way to know from which conversation/chat is each notification from the api?
Without knowing which event is tied to which conversationId how are we meant to know which events are for which conversation?
We are subscribing to this topic: v2.routing.queues.{id}.conversations.messages,
I talked with the messaging development team and their product manager. Right now there is no mechanism to tie the opened message to the conversation id. When you open a message there is a great deal of async behavior going on the backend to create the message and then tie it to a conversation. So the conversation id is not returned in the initial payload from the message endpoint call because the conversation id might not be immediately available.
The development team is currently targeting a new endpoint that will let you look up the conversation id with the message id. Once that endpoint is out there you can look up the conversation id and then map that to the "id" field returned on the notification payload. The product manager for the group is targeting the release of this new endpoint at the end of October.
I would monitor the release notes in October and watch for this feature.
Thanks,
John Carnell
Manager, Developer Engagement
If you can't wait for the new endpoint, there might be some workarounds. I haven't actually tried any of them yet, but RJ sent these ideas to me before he left and I could see them working.
You could POST the conversation ID and external user id back from Architect via a data action. This only works when the message hits the flow though.
You can poll the conversation details analytics query like every 5 minutes and pull new conversations.
Use the GC Notifications service. That service can push notifications whenever a new conversation hits a Queue. that's an elegant way of catching new conversations. Then you can get the external user id and match it up.
My take on the above....
In all of these solutions you would need to use the external user id from the conversation to match up with the open messaging middleware data storage and then store the conversation id in the middleware data. One thing to realize is that if the conversation expires, you will get a new conversation id if the same external user sends in a new message at a later date. I believe this will be a challenge even with the new endpoint. You may want to structure your data model in the middleware in such a way to be able to store historical conversation ids that have at one time been associated to the external user.
By external user Id, can you clarify what Id you mean here? Do you mean the "from: {Id: ""}}" in the /conversations/messages/inbound/open request body?
The goal here is to find a simple real-time way to get events when 1. An Agents joins a conversation 2. An Agent leaves a conversation and 3. An agent transfers a conversation to another Agent.
There does not appear to be a straightforward way to achieve this with the Open Messaging API. It was very simple with the Guest Chat API.
Yes, that is correct. I think we call it the external user id because depending on the direction of the message the "from" and "to" would change and be confusing. The Open Messaging API is a newer product and I know new features are incoming. I would need to lean on product to provide a roadmap and if that roadmap would help your use case. At any rate, subscribing to, or polling conversation events are the only way currently to get the data that you are after.
An additional feature that is "coming soon" is our EventBridge integration with AWS. Once this is released it will have a representation of our conversation details. So instead of polling the API or managing websockets you could use EventBridge to get these updates across all conversations. About the Amazon EventBridge integration - Genesys Cloud Resource Center