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?

User Identity & Access Tokens

In your Programmable Chat application, you will be responsible for two components:

  • A client (browser, iOS, Android) app where users send and receive messages
  • A server which vouches for the identity of your users

This guide will show you how these two pieces work together in your messaging application.

Client: Request an Access Token

When a user in their browser or on their mobile device wants to start sending and receiving messages, Twilio can't trust them right away. Not on this Internet! Twilio needs YOU the developer to vouch for your users, so we can trust them too.

You'll need to give your users an Access Token that tells Twilio who they are and what they can do. In our starter apps, the client requests an Access Token from the server like so.


        Clients should provide a device ID of some kind to uniquely identify which device they are connecting from. You'll probably want to use vendor ID on iOS and ANDROID_ID on Android. In web applications, there's not a great built-in solution for this, but you might consider using a library like fingerprint.js.

        Let's see how we handle this request on the server and create a token for the client.

        Server: Create an Access Token

        On the server we must decide, based on the token request that was sent to us, who the user is and what they should be allowed to do.

        To figure out who the user is (their identity), you might use your existing login system (using session cookies, an API token, or whatever mechanism you use to secure API requests or pages today). You might not care who a user is at all, and assign them a temporary identity as in our starter apps. Who the user is and how you determine that will vary from app to app.

        If you determine that the user should indeed be allowed to access your Chat application, you must grant your user access to Chat and configure an Endpoint ID. Here's how we generate those tokens in our starter apps.


              About Endpoint IDs

              An "endpoint" in Chat is a unique app, device, and user combination that can receive a message. For example, "" using "SquareChat" on her iPhone is a different message delivery destination (endpoint) than "" using "SquareChat" on her Kindle Fire tablet. The endpoint ID you generate on the server - while it can be a string in any format you want - should integrate at least these three dimensions.

              Once your client receives an Access Token from your server, you can initialize the Twilio Chat SDK and start sending and receiving messages.

              Client: Initialize the SDK with an Access Token

              Access Token in hand, we can now initialize the Chat SDK on the client to start doing fun stuff like sending and receiving messages. Here's how you would use the token string to initialize the client, again taken from the starter apps.


                    After you've initialized the client, you can access all of the SDK's features.

                    Token Expiry

                    Before moving on, you'll want to be sure to listen to the tokenExpired event and refresh your token.


                          Now that your token logic is setup, the first thing you're likely to want to do is send and receive messages on a channel. Press on to learn how to make that happen!

                          Next: Channels and Messages »

                          Need some help?

                          We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.