Level up your Twilio API skills in TwilioQuest, an educational game for Mac, Windows, and Linux. Download Now


Rate this page:

Thanks for rating this page!

We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?


Programmable Chat is a cloud-based chat product which provides a number of client SDKs and a REST API for use in integrating Chat capabilities into applications and websites.


Programmable Chat has several core data types or objects which you will interact with:


チャットサービスはチャットのデプロイメントにおいて全チャンネル、メッセージ、ユーザー、そして他のリソースを包含している場所です。 サービスは完全に分離されており、アカウント内に多数のアカウントが存在しても、サービス同士が重複または競合することはありません。

Note: To interact with Chat, you will need to create a Chat Service instance for your SDKs to connect to, and for your backend to be able to control via REST. You can create and configure Chat Service instances in the following places and ways:


Programmable Chat is a user-centric system, and each unique identity connecting to a Chat Service will create a User record.


Within a Chat Service, Users can interact in different ways with the Service itself as well as with Channels, Messages, Users, and Members. A User's Role determines their permissions within a Service and various Channels.


チャンネルはサービス内での全チャットアクティビティーの中心です。 チャンネルのメンバーはチャンネルにメッセージを送信し、それはチャンネルの他のメンバーに配信されます。 チャンネルはprivateまたはpublicになります。

プライベートチャンネルは追加または招待されたユーザー以外には見えません。 プライベートチャンネルのメンバーは十分な権限を持つメンバー、または開発者のビジネスロジックによる制御におけるREST API経由でのみが追加できます。



A User within a Service can interact with Channels as a Member. Members have an assigned Role within a given Channel that dictates what the Member can do within that Channel.


All chat Messages exist within a Service as part of a Channel. Messages are stored in order, and all Members of a Channel can access Messages and create new ones. Note that Member permissions can be modified to limit the actions and data allowed within a Channel via their assigned Role.

Messages can also be edited and removed (subject to Role permissions).


The Chat REST API is used by your backend services and is intended for system usage. The API can be used to orchestrate the usage of Programmable Chat - such as creating a private Channel and adding a customer support agent User as a Member along with the customer User.

Your backend logic can control virtually every aspect of a Service including creating Channels, adding or removing Users and Members, sending Messages and more.


The Programmable Chat SDKs have many shared fundamentals which are important for you to understand to ensure best practices and proper usage. This guide introduces these fundamentals and aims to provide code samples for each SDK.


Twilio's Chat SDKs are used to build 1st person chat experiences in mobile and web applications. These experiences are designed to be user-centric, authenticated and identified by your backend.

All access and interactions from the Chat SDK client endpoints happen in the context of this user identity interacting with Channels and Messages on the Chat Service. It is therefore important for your application to perform any necessary authentication or authorization of the User before generating an Access Token for their identity .


The SDKs interact with the Chat Service over a websocket connection which is established and maintained by the SDK. Communication with the Chat Service is in real time and is bidirectional in nature.


To interact with a Chat Service from an SDK client, a valid Access Token is needed. This Access Token is generated by your backend using the relevant Twilio Helper Library and is cryptographically signed to ensure the contents are trusted by the Chat Service.

You will also need to implement the Token refresh logic if your client uses Access Tokens that are shorter lived than your Chat Client sessions. The optional AccessManager helper is available for all platforms and can assist with this.



The Chat SDKs all follow an asynchronous model of interaction with the Chat Service. This means that commands from the SDK clients do not block synchronously while waiting for the final result of the command (although they will receive a response from the Service upon command acceptance). Instead, event handlers (callback handlers/listeners) must be implemented on the client side to receive and process the asynchronous responses from the service.

Each SDK has a particular mechanism for asynchronous event handlers:

  1. JS: プロミス
  2. iOS: デリゲートとブロック
  3. Android: リスナー

Examples of how these work in various places within the Chat SDKs are found in the more specific guides which follow.

次: SDKの初期化

Rate this page:


誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。