In general, you can failover to SMS or another Verification channel for all error codes. The exception to this is error code 60540, which indicates that the phone number is invalid and an SMS Verification would also fail. We don’t recommend writing specific handling logic for each error code beyond falling back to another Verification channel because error codes may be added or changed over time.
Besides 605xx error codes, there are also client error codes. After the SNA URL is received from a Start New Verification API call, it must be invoked from the client with a GET or POST request. You will receive a HTTP 200 OK as a response (assuming no other issues) and a client error code value.
Success. The carrier was able to determine whether or not the provided phone number matched the detected phone number.
Everything worked correctly.
Make a Verification Check call to find out whether the provided phone number was a match or mismatch.
Failure. There was an issue that prevented the carrier from being able to determine whether or not the provided phone number matched the detected phone number.
A variety of reasons could have caused this error.
Make a Verification Check call to view more specific error codes listed in the response property if supported by the country/carrier:
Fallback to a different Verification channel (e.g. SMS).
Failure. SNA Carrier identified an invalid phone number.
This -40 code is equivalent to the 60540 error code.
See 60540 possible causes.
This error code is currently only returned for Indonesian numbers.
Make a Verification Check call to confirm that a 60540 error occurred.
See 60540 possible solutions.
These error codes can be useful during testing, but it isn’t necessary to use them in production because you can’t use them to make decisions about whether the user is successfully verified or not. You still need to make a subsequent server-to-server Verification Check call for the following reasons:
- To obtain actionable information, such as whether the number matched or not.
- Twilio logs will only display the final status and/or error code for an SNA Verification Attempt after the Verification Check call is made.
We understand that you may want to immediately failover to a different Verification channel, such as SMS, when a non-0 error code is returned or when no response is received within 4 seconds of SNA URL invocation in order to not incur the additional latency of calling the Verification Check API and waiting for a response before failing-over. That’s fine, but we recommend still calling Verification Check in parallel for two reasons:
- Calling Verification Check will add the final status and/or detailed error code of the SNA Verification Attempt to your Twilio logs for reporting/monitoring purposes.
- An attacker who wants to force a failover from SNA to a less secure verification method could spoof a non-0 error code or timeout by gaining access to the client. On the other hand, error codes obtained via the server-to-server Verification Check call are inherently secure as they are obtained using a secured communication channel.