Verifying Caller IDs at Scale
What if you need to make calls in a subaccount using a Twilio phone number provisioned in your Master account? You'll need to verify those outgoing caller IDs with the Twilio account or subaccount you are using.
This guide will be helpful if you have a large number of phone numbers that you need to verify programmatically. If you need to verify a mobile phone or landline number, it may be easier to do so through the Twilio console.
What this guide covers
This guide covers the process you would use to programmatically verify many phone numbers with Twilio. The specifics of the implementation are going to be different, based on the API provider you are using for the phone numbers.
In general, you will start with a list of phone numbers to verify. Make a call to the Twilio API with each phone number to start the verification process. Twilio will respond with a unique six digit verification code for each number.
Twilio will then make a phone call to the phone number from another provider, and that phone number should respond with the six digit verification code. After Twilio either receives or doesn't receive the correct code, a separate status callback request is made to a web URL of your choosing that contains the verification result for that phone number - either success or failure.
This guide uses Twilio Sync to share state between different systems - but you may use another data store, such as Redis or a database. It also uses a Twilio Function to store verification status in Twilio Sync.
- Verifying outgoing caller IDs with Twilio
- Using Twilio Sync to store validation information
- Responding to the Twilio Verification phone call
- Receiving verification status in a callback
- Recording verification status with Twilio Sync
- Retrieving verification status from Twilio Sync
- Next Steps
Verifying outgoing caller IDs with Twilio
Using the Outgoing Caller IDs Resource, you can create a validation request for a phone number. Twilio will return a six digit verification code to you in the response to the create request (synchronously). Twilio will then call that phone number on the PSTN, with a caller ID of +14157234000.
We also set the status callback, so that we can get the verification status for each phone number.
From your non-Twilio phone number (or from a Twilio number not associated with the current account), you will need to answer the incoming call from Twilio. This typically involves configuring a webhook with the third party, however you may be using an incoming voice call webhook on that phone number already. If that's the case, you can either add some logic to the webhook to respond to the inbound Twilio phone number (+14157234000), or temporarily replace the webhook with one that replies back to the Twilio validation request phone call.
When you send the validation request, you will get a six digit verification code in the response. You will have to get that verification code to the webhook that responds to the Twilio incoming phone call. One way to do this would be to use a key/value store like Redis. Another way would be to use Twilio Sync to store the validation code.
Using Twilio Sync to store validation information
Twilio Sync provides shared state in the cloud, so you can store the verification codes in Sync after calling the Verify Outgoing Callers API, and then access those access codes from your phone number's webhook (which probably isn't running on the same system as a script that verifies caller ids). There are two steps - the first is to set up a sync map to store information by phone number. For now, we are only going to store the verification code. Later, we will store verification information, once we retrieve it from the status callback.
We can use the default Sync service - if you are using Sync already, you can also create a new Sync Service from the console or API, and use that. When we create the Sync Map, we give it a unique name, "OutgoingCallerIds" - this can also be whatever you would like to use.
After creating a Sync Map with the REST API (you will only need to do this once), the next step will be to store the verification code from Twilio into that Sync Map. Sync Maps store Map Items, which consist of a data object accessed by a key. The key is a string, and should be unique - the phone number works perfectly as a key. The data can be up to 16 kilobytes in size, and should be structured as key value pairs. We can store the verification code with the key
verification_code. and store the six digit verificiation code as the value.
Responding to the Twilio Verification Phone Call
Depending on your third-party provider, how you respond to an incoming phone call will differ. For instance, your provider may offer a webhook solution that calls a web URL of your choosing with an HTTP POST or GET request.
Your response should be based on the incoming phone number - +14157234000 is the phone number that Twilio will be using to verify your phone number, so you can play back the proper six digit validation code with DTMF.
When your phone number receives the validation request, your program will need to look up that verification code. For instance, if you were using Redis as the data storage, the phone number would likely be the key. If you use Twilio Sync, you can fetch a Map Item from a Sync Map, based on the phone number as the key.
The map item will contain the verification code in the data object. Read that verification code, and then play it back to Twilio, and your phone number will be verified!
Receiving verification status in a callback
After your phone number gets a verification call from Twilio, you can receive a status callback from Twilio to record the verification status for that phone number. This webhook will contain two parameters we are interested in -
To (the number being verified), as well as the other parameters included in a TwiML Voice Request.
Because you may be verifying many numbers, there may be some cases where the verification status fails, and you have to retry those numbers. For those cases, it's helpful to have a record of which verifications were successful, and which were not.
If possible, record the verification status in logs, but also into a key/value store or database, so it is easy to get a list of failed verifications back. Again, we can use Twilio Sync for this.
Recording verification status with Twilio Sync
We will update the Map Item for our phone number in our
OutgoingCallerIds Map. You will need the original key used for the map item - this would be the phone number, in the same format as you stored it. Then you can pass in a new data object - in this case, it would look like
If you like, you could also use another Map, with a different unique name, and then create a Map Item in that Map for the verification status.
Save the Twilio Function, and then it will automatically deploy. Now just supply that URL as the status callback when you verify the Twilio phone number.
Retrieving verification status from Twilio Sync
The REST API for fetching all Map Items for a Map is paginated - if you have more than 50 numbers to verify, you will need to paginate through the list. For more on working with map items, see the Map Item Resource documentation.
After verifying your phone numbers with this account, you should be able to make outgoing calls with Twilio using these numbers for the caller ID.
Here are some additional documentation resources that can help you with this project:
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.