So, you’ve decided to build with the Twilio Conversations API. If you’ve already built applications with Twilio Programmable Chat, many of the concepts, resources, and metaphors in Conversations are already familiar to you.
For existing customers, the good news is that the Conversations API is built on the Programmable Chat foundation, and most of your existing messaging and user data is going to be made available automatically, with no data migration required. However, there are a few key changes you’ll want to make to your application in order to migrate as smoothly as possible.
Twilio Conversations and Programmable Chat share many of the same concepts and even method calls, but in order to support cross-channel messaging, there are a handful of key differences to keep in mind as you build.
In Conversations, chat becomes one of many “channels” for communication. A channel in Conversations is not a resource; it is the method by which a Participant joins a Conversation, such as SMS, WhatsApp, or chat.
Unlike in Programmable Chat, in Conversations, you can build messaging experiences that connect users from multiple channels. For example, a customer on their phone can send SMS messages that a customer service agent receives through a web chat interface on their computer. On the other hand, you can build single-channel Conversations, such as Conversations between only chat Participants or SMS Participants.
To add SMS or WhatsApp Participant to a Conversation that was previously a Chat Channel, you will need to update the Conversation with a Messaging Service SID. A Messaging Service is a Messaging Resource that allows you to bundle multiple sender types together.
As part of this migration, Programmable Chat Services become “Conversation Services.” You can fetch these Services through the REST API with the same SIDs (
ISXXX...) and Conversations, just like before.
As with Programmable Chat, you can use any number of Services in Conversations. The same rules apply: the data is not shared between Services.
For convenience, Twilio Conversations introduces a single "default" Service that appears in the REST API at the account level, linked to your Account SID (
ACXXX...) If your app only relies on a single Conversation Service instance, you could choose that Service as the default. To separate your Conversations by use case, you can also create sub-accounts.
You can read more about Conversations Services in our guide to Conversations Fundamentals.
All Conversations are private; this is a change from the concept of public vs. private Channels in Twilio Chat.
Public Chat Channels do not exist in the Conversations API. This means that existing public Chat Channels are not visible in Conversations. Please plan accordingly. If there are any public Chat Channels that you wish to use in Conversations, you should create a new private Channel, which will be available as a Conversation resource through the Conversations REST API. Alternatively, you could create a new Conversation resource using the REST API with the same Participants that you had in your public Chat Channel.
If you no longer need public Channels in Conversations, you can leave them; public Channels won't be visible in Conversations.
Please be aware of the following vocabulary changes in your migration from Programmable Chat to Conversations:
Most customer data from Programmable Chat (such as Services, Channels, Users, Roles) are available in Conversations automatically.
For example, Programmable Chat Channels become Conversations. You can retrieve them by making a GET request to the Conversations resource or fetching a single Conversation by its SID. Conveniently, the Conversation SID is the same as the Chat Channel SID; it will look like
If you are building a chat-only Conversations (not connecting SMS Participants, for example), all of your data is already availble in Conversations. There is no migration required.
To learn more about migrating from Twilio Programmable Messaging to Conversations, please see our guide about Inbound Message Handling and Autocreation.
Your existing Channels in Programmable Chat will migrate to Twilio Conversations; all Channels are visible in Conversations.
However, there are two things to keep in mind:
- Public Chat Channels will not be visible or available throught the Conversations REST API because all Conversations are private.
- Before you can include non-chat Participants (SMS or WhatsApp), you’ll need to attach a Messaging Service SID to the newly migrated Conversation.
As mentioned above, some features in Chat have been renamed in Conversations. For example, rather than referencing a Channel, Conversations calls the equivalent resource a Conversation.
In your application code, we suggest the following adjustments:
- Instead of
ChatClient, you should import and refer to a
- Wherever you used to refer to Channels, you should refer to Conversations (REST API).
- Where you had a Chat Member object, you will now have a Conversations Participant object (REST API)
|In-App chat functionality
Build chat-based experiences in for the browser and mobile using our SDKs
A public Channel is seen and can be joined by non-members. All Conversations are private; the Participant must be a part of Conversation to view the messages.
With this feature participants are asked to join a conversation and must approve the request before being added.
Conversations supports cross-channel messaging over SMS, MMS, chat, and WhatsApp
Delivery ReceiptsStatus of the Message: sent, delivered, read, failed, undelivered. These are rendered in Messaging Insights and via webhook for troubleshooting and understanding message engagement.
States & TimersState of the conversation: active, inactive and closed. Timers are set to automatically transition from state to state. These features allow employees to focus on active threads and limit the number of unused conversations.
Group MMS (“Group Texting”)
Supports a native group texting conversation of up to four participants using MMS. This feature is only available in the US and Canada.
Multiple Services Support
Businesses may wish to use multiple Services for different use cases or, in the case of ISVs developing on Conversations, a different Service for each organization.
Push (+ related bindings and credentials)
This feature allows chat participants to be notified with mobile push notifications.
Reachability indicates the availability of a chat participant. Participants can toggle between available and unavailable for message routing purposes.
Message Consumption Horizon for Programmable Chat allows a User's Message read status to synchronize across devices and endpoints.
With Twilio Conversations, you can still build the Programmable Chat experiences that your end users know and love...but with more features and the ability to connect participants over SMS, WhatsApp, and chat.
After migrating, take a look at the following documentation to build more feature-rich Conversations today:
誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。