We're excited to announce that Verify, our API for Two-Factor Authentication (2FA), has just had Version 2 released for General Availability! This evolution of our 2FA solution has been designed to work better for developers by using Webhooks for asynchronous integrations and offering more options and flexibility. Let's go through the differences between V1 and V2. You can also check out a comprehensive guide to switching versions on this page in our documentation.
Version 1 of Verify was designed to have a more synchronous flow - an example of this is after starting a request, the API needs to be polled if you need to know the status of the request before the user submits a PIN code (which effectively counts as the 'start' and 'end' of the request lifecycle).
The first iteration of Verify was built around a synchronous flow, with API polling required to check the status of a request after its initiation and before submitting the user's PIN code.
In contrast, Verify Version 2 harnesses the power of webhooks. Initiating a request now provides you with a unique GUID. Assuming JWTs are your authorization method, your integration will listen for incoming webhooks corresponding to the GUID request for updates. The associated endpoints with these webhooks are:
Initiate the request
Verify the user's PIN
Cancel a request
With the surge in fraudulent activity exploiting Communications APIs, we have integrated the Verify Anti-Fraud System with Version 2. This system detects suspicious activity and triggers a Network Block. For added flexibility, users can also customize this feature according to their requirements if necessary.
The most significant change we've made to the API is adding new communication channel options. When you start a new request, the following existing methods can be used:
SMS
Voice Text to Speech (TTS)
You can now use these new methods:
WhatsApp
WhatsApp (Interactive Yes/No prompt)
Email
Silent Authentication
I make that a product expansion of... 200%!
Related to the new channels, you can now control exactly how your request workflow is structured. Previously, you would send a workflow_id in the request, taken from a predefined list in our developer portal. Instead, for V2, you can include a custom payload for your workflow. For instance, if you want the attempted order of channels to be Silent Auth -> Email -> SMS, the request would look like this:
{
"brand": "ACME, Inc",
"workflow": [
{
"channel": "silent_auth",
"to": "44770090000X"
},
{
"channel": "email",
"to": "alice@company.com",
"from": "bob@company.com"
},
{
"channel": "sms",
"to": "44770090000X"
}
]
}
Developers also can send a custom code for channels that require it (i.e., all apart from WhatsApp Interactive and Silent Authentication). This code can be between 4 and 10 characters in length and is alphanumeric. Here's an example of the JSON payload sent when using your own generated PIN:
{
"brand": "ACME, Inc",
"code" : "R4Fe4dR1Qz",
"workflow": [
{
"channel": "sms",
"to": "447700900000"
}
]
}
Version 2 of Verify makes better use of HTTP response codes. Yes, yes, OK: so not REST (I just wanted to put it in the heading), but better use of the HTTP protocol. Here are some examples:
When starting a request that has already run, you get a 409 response.
Hitting the rate limit now gives you a standard 429
An invalid payload for either the request start or PIN submission endpoints gives you a 422
This one is quite a nice use case: if you submit an incorrect PIN too many times, you eventually get a 410 to indicate the request entity is now no longer available for any state changes.
The new channels we've launched now give developers a wealth of options to integrate 2FA into their systems, side projects, and enterprise applications. The question is, what have you built? A passionate side-project turned startup with Laravel or Rails? A rollout across a Node microservice architected enterprise? We want to know! Head to our Community Slack to talk to us.
){kind=small}
