How many Phone Numbers do I need?
Public Beta
Twilio's Proxy API is currently available as a Public Beta product. Some features are not yet implemented and others may be changed before the product is declared as Generally Available.
Public Beta products are not covered by a Twilio SLA.
Warning
We strongly recommend you read the Proxy Phone Number Management introduction first.
An important setup task with Twilio Proxy is adding phone numbers to your Proxy Service, as you'll see from the quickstart and REST API documentation. How many phone numbers should you add to your service?
In the quickstart, you add only a single number with no additional configuration options set. This means that Proxy will use that single number to pair Participants in each Session. If you try and pair the same individuals in additional Sessions while the first Session is still open, you'll get an error because Proxy has used all available numbers.
The exact "number of numbers" you'll need in the Proxy number pool is based on a number of factors, but the Proxy number rule of thumb comes from this question:
This question is crucial for assessing how many Twilio numbers will be required in the Service. The reason is that one single participant cannot be assigned to the same Proxy number in concurrently active (open or in-progress) sessions. So if the same participant will be active in two concurrent sessions, at least two Twilio numbers will be required as Proxy Numbers in the Service. That being said, one single proxy Identifier (the Twilio number in the Service) can be used in multiple active sessions, but by distinct participants.
Let's illustrate this with an example. Let's suppose we have a ride-sharing app where a driver is paired with only one passenger at a time, and the Session closes as soon as the ride is complete. In this case, we can use a single Twilio number in the Service*. In the table, we describe each ride's Sessions:
| Session | Driver | Passenger |
|---|---|---|
| A (Driver A, Passenger A) From 10AM to 10:20AM | Using Proxy Number 1 | Using Proxy Number 1 |
| B (Driver A, Passenger B) From 10:25AM to 11AM | Using Proxy Number 1 | Using Proxy Number 1 |
This works because at any given time, when Driver A calls Proxy Number 1, she will reach her current passenger. Note, a passenger cannot call or message the driver after the ride is complete since their respective Session will have closed.
But now let's say that we need a way for the Driver or Passenger to get in touch for some period of time after the ride - for example, the Passenger left his wallet in the car and the Driver needs to let him know. In order to enable this, we'll need to keep the Session in-progress even after the ride is complete (let's say the ride takes 1 hour). In this case, because the Driver may need to be able to communicate with both passengers during the overlap time, she'll need two different Proxy Numbers. Let's illustrate this with a table:
| Session | Driver | Passenger |
|---|---|---|
| A (Driver A, Passenger A) From 10AM to 11:20AM | Using Proxy Number 1 | Using Any Proxy Number** |
| B (Driver A, Passenger B) From 10:25AM to 11AM | Using Proxy Number 2 | Using Any Proxy Number** |
From 10:25AM to 11:20AM, the Driver will be a participant in two active Sessions. Thus, we'll need at least two Proxy Numbers in our pool to allow Driver to have a unique Proxy Number as identifier per active Session.
Remember: The best time to create a Session is when it's needed. For example, show a "Call" button in-app, then create the Session and add the Participants, and then finally retrieve the assigned phone numbers.
* For simplicity, we will use the minimum number of Proxy numbers required in the Service.
** For this example, the Proxy Number assigned to the Passenger is irrelevant. It is worth clarifying, though, that when you allow Proxy to assign Proxy Numbers to Participants, sometimes both Participants will have the same Proxy Number (especially when you have very few numbers in your pool). This is fine but is by no means a requirement.
At high scale, the limiting factor for how many Sessions can concurrently use one Phone Number is phone number reputation and messaging compliance status, not a fixed session count.
Capacity also varies by country. US and Canadian numbers, particularly toll-free numbers, can sustain very high concurrency. Numbers in other countries are sometimes tied to a carrier switch with real, much lower concurrency limits, so validate capacity for each country you deploy in rather than assuming US-level throughput everywhere.
Protect number reputation and compliance
Carriers throttle or block traffic based on a phone number's reputation and compliance status, not a raw session count. To maximize throughput and keep delivery healthy at scale:
Voice
- Register the phone number with Voice Integrity. This is essential for reliable call delivery.
- Balance call direction. Numbers that place far more calls than they receive, such as dialers, are more likely to be marked as spam.
- Favor longer calls where possible. Call duration factors into reputation scoring.
- Register a CNAM so carriers display your business name instead of a generic spam label.
- Let a number build tenure. Newly activated or unregistered numbers are treated with more suspicion.
- Monitor number health with Voice Insights Trust & Engagement Insights, which tracks trust scores, degrading metrics, and blocked numbers over time.
- If a number's reputation degrades, remediate it instead of replacing it. Recycling numbers doesn't reliably fix reputation issues.
Messaging
Keep your A2P 10DLC campaign registration active and matched to your sending volume. Campaign and brand type set your message throughput ceiling.
Twilio doesn't automatically rotate numbers as your session volume grows, so expand your pool proactively if you expect it to increase.
Strict geo-matching rules significantly increase your pool size requirements. With area-code or extended-area-code matching, you need local numbers in every area code where your participants are active. A service with participants spread across 20 area codes requires at least 20 numbers to guarantee a successful match — more if concurrent sessions within the same area code are common.
When adding Participants to a Session, you receive an error if your Proxy Phone Number pool has no available Phone Numbers. Twilio reports this error to debugger events. To anticipate shortages before they occur, monitor your active session count using the Sessions list resource and compare it against the number of phone numbers in your pool.
If you've read our guide to Phone Number Management and still have questions about scoping your number pool, contact us using the support channel below.
You're ready to dig into the Proxy API Reference next.