Rate this page:

Authy Users

As of November 2022, Twilio no longer provides support for Authy SMS/Voice-only customers. Customers who were also using Authy TOTP or Push prior to March 1, 2023 are still supported. The Authy API is now closed to new customers and will be fully deprecated in the future.

For new development, we encourage you to use the Verify v2 API.

Existing customers will not be impacted at this time until Authy API has reached End of Life. For more information about migration, see Migrating from Authy to Verify for SMS.

Before you can secure a user with the Twilio Authy API, you need to create a user. The API requires you set an email, phone number and country code for each user.

When a user is first created, you will receive an authyid which you must then store with the user's profile in your own database. Do not lose this ID - you will use it every time you wish to authenticate a user!

Your users can change their phone number registered with the API without your knowledge by using the Authy Mobile or Desktop Application. They may also use the phone change security review. You can get webhooks of when this phone number changes via our Webhooks API.

Loading Code Sample...

        Create an Authy User

        A user may have multiple email addresses but only one phone is associated with each authy_id. Two separate API calls to register a user with the same device and different emails will return the same authy_id and store both emails for that user.



        Name Type Description
        user[email] String (required) More than one email can be stored per AuthyID, but only the initially created email will display in the Dashboard until it is removed. (📇 PII )
        user[cellphone] String (required) Foreign key for the AuthyID (the AuthyID will be the primary key going forward). You can use dashes, periods, spaces or nothing to separate parts of the cell phone number. (📇 PII )
        user[country_code] String (required) Numeric calling country code of the country Eg: 1 for the US. 91 for India. 52 for Mexico. See: Country code list dropdown (🏢 not PII )
        send_install_link_via_sms Boolean (optional) Enable or disable an sms message with a link to download the Authy App. See Sending Install Link for detailed behavior. Default can be set from the console. (🏢 not PII )


        Name Type Description
        user User user object contains the AuthyID of the created user. (🏢 not PII )
        message String A message indicating the result of the operation. (🏢 not PII )
        success Boolean True if the request was successful. (🏢 not PII )

        Email and phone number must be valid for the request to succeed. An invalid request will produce the following error response:

          "message": "User was not valid",
          "success": false,
          "errors": {
            "email": "is invalid",
            "message": "User was not valid"
          "email": "is invalid",
          "error_code": "60027"

        Sending Install Link

        The send_install_link_via_sms parameter will override behavior set in the console. Check your application's settings. Note: the parameter is ignored and no install link will be sent if the user has synced a device with the Authy servers in the previous 90 days. You can see last_sync_date for a user's devices via the User Status endpoint.

        If you want to send an install link regardless, we recommend using Twilio Programmable SMS (note: requires a Twilio Phone Number). Include the URL which will autodetect the device type and redirect the user to the appropriate download link. See the SMS docs for more information.

        [Optional] Allow user to set up other authenticator apps like Google Authenticator

        Enrolling a user (if you use the same phone number they used to sign up for the Authy App) automatically adds your application to their Authy App. You do not need to do any additional work to support TOTP tokens in the Authy app. To support additional Authenticator apps, like Google Authenticator, display a QR code to your users that contain a compatible TOTP secret. The API will return a link to a valid QR code. Instructions for generating that QR code are in the One-Time Passcodes reference documentation.

        Add a user without providing email or phone number

        You might not have the email and the phone number of the user, or if you do, you might not want to share it with Twilio for compliance reasons.

        For those cases you can use our Authy App based onboarding flow. The end user must have the Authy App installed and registered, meaning the end user has already provided their phone number and email to us.

        This feature is only supported in the following versions of the Authy App. End users will have to update their mobile applications to the following versions:

        • iOS 22.4+
        • Android 23.8+

        Create a JWT

        Loading Code Sample...

              No-PII user registration JWT

              First, create a JWT. The token will be used to tie the end user's Authy ID to your application. The token must:

              1. Follow RFC 7519.
              2. Be signed with your application's Production API Key found in the Twilio console.
              3. Contain the following:


                "iss": "{authy_app_name}",
                "iat": {issue date in NumericDate},
                "exp": {expiration date in NumericDate},
                "context": {
                  "custom_user_id": "{custom_user_id}",
                  "authy_app_id": "{app_authy_id}"


              HS256 is the only algorithm supported.

                "alg": "HS256",
                "typ": "JWT"


              The issuer param in the JWT payload MUST be the Application name, other value will raise an error in the validation.


              The date the JWT is issued. The difference between iat and exp cannot be more than 15 minutes.


              The expiration time of the JWT. Used to prevent the JWT from being reused in the future. Maximum expiration time allowed is 15 minutes after the current time.


              Provided by you, uniquely identifies a user. We are not expecting PII or any sensitive data, so please do not provide phone numbers, emails, SSN, or other identifying information. If you only have PII to identify your users we recommend to either:

              • Create a de-identified ID like a UUID

              • De-identify the PII by sending us the HMAC of the PII. Use URL safe Base64 encoding.


              The application id can be retrieved from console by going to Applications selecting the Application, and browsing to settings.

              During development, you can validate your JWT using The example can be found here.

              Create a QR Code

              Next, create a QR string with the following format:

              Loading Code Sample...

                    Example No-PII user registration QR String

                    Generate the QR Code from the transaction string

                    Note: we do not recommend storing the QR code since it can potentially leak sensitive data. Instead, we recommend:

                    1. Sending the QR code as a base64 encoded image in your HTML
                    2. Generating the QR code from your application with a library like For testing, you can use an online generator like

                    After the QR code is generated display it so your user can scan it with the Authy App.

                    Keep in mind the QR codes expire, so don't display it for more time than the assigned expiration. The mobile device requires internet connectivity to complete the flow.

                    No-PII Registration: Get the User's Authy ID

                    After the end user scans the QR code there are two ways to get the user's Authy ID (required for subsequent verification challenges).

                    1. Poll registration status
                    2. Subscribe to a registration webhook

                    1. Poll registration status



                    Name Description
                    The format to expect back from the REST API call. json or xml.
                    ID provided by you to uniquely identify a user. (🏢 not PII )

                    Response Parameters

                    Name Description
                    Possible responses:
                    "pending", the user didn't scan the QR code yet.
                    "expired", the received JWT was expired, it was either created with a short duration or the user took to long to scan.
                    "completed", the user was successfully added. Make sure you keep your time in sync with an NTP server.
                    Uniquely identifies a user in the Authy API. Use this ID to call other Authy API endpoints.
                    Loading Code Sample...

                          Get No-PII User Registration Status

                          2. Subscribe to a registration webhook

                          You can subscribe to a webhook that will notify you in real time when the registration is successful or not.

                          The payload for event user_registration_completed:

                          ```{ "method": "POST", "params": { "events": [ { "event": "user_registration_completed", "time": "2019-04-09T22:26:10.503Z", "objects": { "app": { "b_custom_code_allowed": false, "b_custom_message_allowed": false, "s_account_sid": "AC5f123456eabfa99ee3441ef1e84ad528", "s_device_app": null, "s_errors": "", "s_id": "54321", "s_name": "Application Name", "s_type": null }, "registration": { "s_app_id": 54321, "s_authy_id": 123456, "s_custom_id": "885de433faedf8475426f11baeee2424f88fd935" }, "user": { "as_authy_ids": [ "123456" ], "b_banned": false, "s_authy_id": "123456", "s_country_code": "57", "s_errors": "", "s_locale": "en", "s_phone_number": "953a0fd8c9ec2a9f16a5ce58183cfa03" } }, "request": { "id": "413fd53c-09af-43d6-8390-c346de8ccf0c", "ip": "IPv4_99a65f1a9e58fe49150aed5a188459b9b0b47157" }, "public": true } ], "webhook_id": "WH_50087ea9-9568-4839-9191-b43908a4abd4" }, "url": "" }

                          The payload for event `user_registration_failed`:

                          { "method": "POST", "params": { "events": [ { "event": "user_registration_failed", "time": "2019-04-09T22:26:10.503Z", "objects": { "app": { "b_custom_code_allowed": false, "b_custom_message_allowed": false, "s_account_sid": "AC5f586933eabfa99ee3441ef1e84ad528", "s_device_app": null, "s_errors": "", "s_id": "54321", "s_name": "Application Name", "s_type": null }, "error": { "s_code": "60000" } }, "request": { "id": "413fd53c-09af-43d6-8390-c346de8ccf0c", "ip": "IPv4_99a65f1a9e58fe49150aed5a188459b9b0b47157" }, "public": true } ], "webhook_id": "WH_50087ea9-9568-4839-9191-b43908a4abd4" }, "url": "" } ```

                          Request User Status

                          Loading Code Sample...

                                Get User Status

                                The user status endpoint will only return a subset of the information for a given user, until that user has verified a token or approved/denied a OneTouch request.

                                Once a user is created and registered with your application, you can request information on that user from Twilio. Using the User status call, you will receive:

                                Response Parameter Description
                                country_code Country code of the phone number.
                                phone_number Last 4 digits of phone number (XXX-XXX-1234). None if the user was registered without providing phone number.
                                email Email provided when the user was added. None If user was added without email this field will be empty.
                                devices List of devices, options are: android, android_tablet, ios, iphone, iphone_sdk, chrome, authy_chrome, sms, android_sdk

                                List of devices including detailed registration information. See Detailed Devices below.


                                Useful for determining a chain of trust. See Authy trust-chain for added devices for more information. Devices deleted before June 15th 2019 won't be returned.

                                multidevice_updated_at Unix timestamp of the last time the user changed the multidevice toggle status (true/false) on any device
                                mutidevice_enabled true if multidevice is enabled, false if multidevice is disabled.
                                registered true when the Authy Mobile/Desktop App was registered.
                                confirmed true when the user has used a valid code before.

                                Trust-chain for Added Devices and detailed device response fields

                                Determine which end-user apps to trust for authentication. Our API records uniquely identifiable numbers for every installed app, as well as the sequence of app installs and the methods of installation. More information in our blog post: Authy trust-chain for added devices.

                                Information returned in the detailed_device section of the user status endpoint includes:

                                • registration_method: how the device was added (sms, call, push).
                                • last_sync_date: Unix timestamp of last time the device was synced with Authy servers.
                                • registration_device_id: device ID of the approving device if registration_method is push. New as of 2019-06-15, devices added before this date will be null. See Authy trust-chain for added devices for more information
                                • enabled_unlock_methods: one or more of pin, faceid, fingerprint, password, none, unknown. Refers to the unlock method for the entire app, not just the settings page.
                                  • Only available for iOS app version 22.8+, Android app version 23.9.3+, and Desktop app version v1.8.0+
                                  • Not available for Chrome app
                                  • If an unlock method is enabled for iOS app, the linked Apple Watch app will still display non-transactional TOTP codes without requiring an unlock, but it will not allow a user to accept a push request.
                                • last_unlock_method: enabled method last used.
                                • last_unlock_date: Unix timestamp of last time the device was unlocked.


                                Name Description
                                The format to expect back from the REST API call. json or xml.
                                The Authy ID of the user. Create an Authy ID by registering a user. Note that password delivery may be upgraded to use the Authy application; see response parameters below.


                                Name Description
                                IP of the user requesting to see the application details. Optional. (📇 PII )


                                Name Description
                                Information about the user. (🏢 not PII )
                                A message indicating the result of the operation. (🏢 not PII )
                                True if the request was successful. (🏢 not PII )

                                Remove a User

                                Loading Code Sample...

                                      Remove a User

                                      If you want to remove a user from your application you can use the Remove API. Note: removing a user will immediately disable token verifications.

                                      Best practice is to remove a user if they disable Two-factor Authentication or remove an account with your App. If you accidentally remove a user, you can recover users through the Console - but we suggest that you instead go through your registration flow again.

                                      curl -X POST{FORMAT}/users/{USER ID}/remove -H "X-Authy-API-Key: {KEY}"


                                      Name Type Description
                                      user_ip String (optional) The ip requesting to remove the user (📇 PII )


                                      Name Type Description
                                      success Boolean True if the user was scheduled for deletion. (🏢 not PII )
                                      message String A messaging indicating the result of the operation. (🏢 not PII )
                                      Rate this page:

                                      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 by visiting Twilio's Stack Overflow Collective or browsing the Twilio tag on Stack Overflow.

                                      Loading Code Sample...

                                            Thank you for your feedback!

                                            Please select the reason(s) for your feedback. The additional information you provide helps us improve our documentation:

                                            Sending your feedback...
                                            🎉 Thank you for your feedback!
                                            Something went wrong. Please try again.

                                            Thanks for your feedback!