Authy Users

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.

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

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 https://authy.com/download/ which will autodetect the device type and redirect the user to the appropriate download link. See the SMS docs for more information.

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.

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.

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:

HS256 is the only algorithm supported.

During development, you can validate your JWT using https://jwt.io/. The example can be found here.

Next, create a QR string with the following format:

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 github.com/skip2/go-qrcode . For testing, you can use an online generator like https://www.qr-code-generator.com/ .

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

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

URL

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:

The payload for event user_registration_failed:

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:

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.

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.