Should I be using the Channels API or a custom channel or both?
Our Channels API provides a unique set of endpoints that differs from our normal custom channels
incoming_messages endpoint. When using our Channels API you'll get your own custom channel type in Front. For more on the differences check out "When should I use the Channels API?"
Do you have any resources or examples I can use to get started?
We have a sample channel you can check out which also includes a Postman collection you can use to jump-start your understanding and development with the Channels API.
How does Front communicate which user sent the message to my system?
The only information provided is the user's contact in Front. Our recommendation is to either 1) define a mapping from Front contact to the user in your system, or 2) match the user's Front contact to that in your system. If no match is present, a default should be assumed.
How does Front determine how messages will thread for my channel?
Front doesn't determine the threading when you power your custom channel using our Channels API, you get to determine the threading. In our Channels API Reference you'll find an
external_conversation_id value can be set which defines the threading value. This could be something of significance from your system that represents the interaction. For example, maybe each time a customer initiates a question in your system a unique ID is assigned to the interaction. Your threading value could be that ID from your backend system. Likewise, if they ask a question about something else or initiate a new inquiry for another line of your product, maybe the threading value should change (eg. different return pages for e-commerce).
By submitting two different thread IDs it will create two different conversations in Front. This way, each conversation can be visually distinct in the conversation list in Front, assigned to the respective team, tagged separately, unique in analytics (etc.). Alternatively, you want your messages to be threaded by the requesting user instead, for an SMS-like channel, you can use a unique identifier for your user (like a user ID or email address).
What is the difference between the
external_id and the
One affects the threading of the conversation while the other does not. The
external_conversation_id dictates how the message will thread when you import it to Front (see above for examples). The
external_id on the other hand has no impact on threading in Front and should simply reflect the unique corresponding message-id value from your opposing system. For example, let's say you were building a custom chat channel in Front and your customer Jim ([email protected]) sends you a response that you need to import to Front. When your backend system receives the message from Jim it assigns it a random string of
ZWW8lX27gZdUDO0uctFG. When you call the receive inbound message endpoint, you might set the
external_id value to
ZWW8lX27gZdUDO0uctFG to match your backend and the
[email protected] so that everything Jim always threads to the same conversation in Front.
How will I know which user in Front sent an outbound message on the channel?
When a message is composed in Front, you'll receive a webhook from us to the webhook URL you define containing things like the
conversation_id but you'll also receive information about the author of the message in Front on the
author object. Things like the Teammate ID, email, username, and name will all be contained in that object. The author reflects who physically hit send on the message in Front.
I've built a great channel many customers of Front would want. How do I make it usable by all Front customers? How do I get it into the app directory?
Follow the directions for publishing your app and we'll work with you to offer this as a channel for all Front customers.
Updated 5 months ago