Native Channels
Freshdesk Messaging (formerly known as Freshchat) has native integrations with WhatsApp, Line, ABC, GBM and FB Messenger.
Channels via Marketplace gallery
Integrations such as MessageBird and Twilio allow customers to use SMS as a channel via the Freshworks Marketplace.
Bring Your Own Channel
The serverless component of Freshworks apps allows you to bring your own channel (BYOC) to Freshdesk Messaging.
What you essentially require is a two-way communication between Freshdesk Messaging and the channel you wish to integrate.
This can be achieved with the help of APIs and webhooks exposed by both, Freshdesk Messaging and the channel you wish to integrate.
For the sake of this discussion, let’s assume that the channel you wish to integrate is Viber.
The Integration
Actors
User: The end-user who initiates a conversation with the business using the Viber app.
Agent: The representative of the business who responds to messages from the User.
In order to establish a 2-way communication, we need to ensure that messages from Viber are delivered to Freshdesk Messaging and vice-versa.
But, the problem is that they cannot talk to each other directly. They require a layer that can translate messages to a format that the recipients can understand.
The Marketplace serverless component is that layer which receives events from both Viber (via Viber webhook) and Freshdesk Messaging (via Product Events) and dispatches messages to the recipients via APIs.
The Marketplace app is involved in 4 distinct interactions as shown in the Figure 1.
1. Viber Webhook
When the Marketplace app is installed, in the onAppInstall event, it can generate a target URL that can be registered as webhook in Viber using the Setting a webhook API.
Now that the webhook is registered, when a Viber user sends a message to the target business, Viber will call the serverless app’s externalEventUrl with the payload containing the message and the user’s attributes. This payload will contain a unique identifier of the user (Viber user id).
2. FD Messaging API
Once the serverless app has received the message, it needs to lookup that user (using Viber user id) in FD Messaging.
This can be done via the GET /users.
If no user exists, then we can create a new user using POST /users.
If a user exists for the given identifier, we can fetch existing conversations using the GET /users/{user_id}/conversations.
Now we need to send a message on a conversation belonging to the user.
Depending on whether a conversation already exists or not, we need to call one of the two conversation APIs.
If no conversation exists, call the POST /conversations to create a new one and send a message on it.
If there already exists a conversation, just send a message on that conversation using POST /conversations/{conversation_id}/messages.
3. Product Events
When an agent responds to a conversation, it is received by the serverless app via Product Events. The onMessageCreate event will receive the payload that will contain the message that was sent and the associated user and agent models.
The user model would contain the identifier (Viber user id) that can be used to uniquely identify the user in Viber.
4. Viber API
With the help of the user identifier from the Product Events, we can now relay the message to the user via Viber’s Send Message API.
Viber will then deliver the message to the user.
Conclusion
The Viber example could easily be replaced with any other messaging channel provided it exposes webhooks and APIs.
In some cases, the webhook registration might be a manual activity. If so, the onAppInstall event can store the generated url in the Data Store provided by Marketplace. It can be fetched back in the app’s custom settings page displayed to the Admin, who can then manually copy and paste it in the target channel’s webhook configuration.
Note: Not all messaging channels allow direct usage of their APIs. You might need to work with a partner to gain access to their APIs like the Viber Messaging Partners.