My company has a custom app for customers and we would like to integrate some type of messaging between customers and employees. We would like to be able to have the customer send messages that may get answered immediately or a little later if no one is available at the time. We would like users to be able to walk away from a conversation and come back to resume later.
WebChat Guest API looks like it is just for short-lived live chat sessions responded to by agents in a queue. WebMessaging Guest API looks good except I don't see a way to notify the customer that a new message has arrived if they have the app closed. Seems like they would only see any new messages if they went back to the app. Open Messaging looks good because it has the webhook that can be used to send notifications to the device that a new message has arrived even if the user has the app closed. But I don't see a "Guest API" for messaging. It looks like even the customers would have to be authenticated through OAuth. (Our server uses older ASP.NET Identity for authentication of customers.
Can anyone give me some advice as to which type of messaging I should look into?
So, your summaries are pretty good, but some advice and pointers:
WebChat Guest API - Correct, it is used for real time, short lived conversations and not really for a messaging platform. WebMessaging Guest API - This is ideal for web based messaging and could be considered a replacement for web chat. If the messaging is to be from a web page or mobile app owned by the customer, then this is the API we have built. We use it for our own UI that is packaged as part of the config, so the API is only needed if you don't want to use that. There is even some specific code and APIs for mobile apps here https://developer.genesys.cloud/commdigital/digital/webmessaging/messenger-transport-mobile-sdk/ using Kotlin and a React Native version in the works with a UI included.. There is no notification system as yet as you can see, but that is also in development to be a standard feature in the first half of this year. Other customers have used their own notification systems to trigger updates. Open Messaging - this was designed for 3rd party integrations to messaging systems that exist and have their own UI. Think things like Kakao Talk, WeChat, Viber, Telegram, but also things like YouTube comments or even Teams IM. They are a bit less defined in what they all do than Web Messaging, so we have an Open API to absorb the messages and sessions. There is no guest API as it is effectively one in it's own right as there is no UI. Think of it as an open equivalent to what we do with WhatsApp anf Facebook Messenger.
For the custom app, I would suggest the Web Messaging API as that is more aligned with messaging on a mobile app.
Thanks for the quick response. We will look into the Web Messaging API. I have two questions about it.
I assume that incoming messages get routed to a queue just like web chat. If there is no one on queue at the time what happens to the message? Does it just wait until someone comes on queue and then get routed to them?
Glad to hear that you are building a notification system for Web Messaging. In the meantime, you mention that other customers have used their own notification systems. How did they trigger them? When an employee sends an outgoing message is there some kind of event that we can hook into to call our notification system?
Yes, that concept is essentially the same between web chat and web messaging.
If you implement the web messaging connection (a WebSocket) directly in the client app, the communication path is directly between the customer's device and Genesys Cloud and relies on the customer to maintain that connection to receive data.
If you develop middleware that sits between the customer's device and Genesys Cloud, that middleware can maintain the connection with Genesys Cloud and then can relay that message to the customer's device using whatever transport you've developed. This could take the form of your middleware sending push notifications to your mobile app, for example. This can ultimately take any form you like; both the middleware and client application are of your own creation in this situation.
OK, I understand tim.smith's answer above where we could develop our own middleware that talks to the Web Messaging API and then when an outgoing message is detected we could call our own code for sending a push notification. This is certainly an option for us.
However, I'm not sure I understand msassoon's answer. It sounds like we could use Process Automation to trigger something. I see that there is a way to trigger a workflow based on an outbound message which I think is what we want ( * v2.detail.events.conversation.{id}.outbound). What I don't see is how a workflow could call our service to send push notifications. I see this page has a list of actions and tasks that a workflow can do, but I don't see anything there that looks like it can call an external service or webhook.
I think Tim's suggestion makes the most sense if there is a middleware and not just a UI. Otherwise, workflows are Architect flows (About Architect - Genesys Cloud Resource Center) and they trigger Data Actions as described here About the data actions integrations - Genesys Cloud Resource Center. If you have someone in your business that manages Genesys Cloud and builds Architect flows, they can guide you to building REST requests to an external service.