WhatsApp API Multiple Numbers: Limits, Sharing, Routing
One WhatsApp number stops being enough sooner than most teams expect. You open a second city, launch a second brand, split sales from support, or want notifications coming from a different number than the one customers chat with. Then the questions start: how many numbers can you register, which limits are per number and which are shared, and how does your code know which number a message came in on?
This guide answers those questions for WhatsApp API multiple numbers on Meta's Cloud API, as of October 2026, then shows how to route inbound and outbound messages in code, and how the same setup works when the numbers are existing WhatsApp numbers linked to a shared workspace instead.
How numbers sit on Cloud API
Meta's structure has three layers. A business portfolio (formerly Business Manager) owns one or more WhatsApp Business Accounts (WABAs), and each WABA holds one or more business phone numbers. Templates and billing live at the WABA level; quality and display names live on each number.
The number cap is set per portfolio. Per Meta's phone numbers docs, new business portfolios can register two business phone numbers. Meta raises the cap to 20 automatically once the business is verified or reaches a messaging limit of 2,000. Numbers can also be migrated from one WABA to another.
That gives you a choice of layout:
- One WABA, several numbers. Numbers share the same templates and payment method. Good for one brand with regional or departmental numbers.
- Several WABAs under one portfolio. Each brand or business unit gets its own templates and its own payment method. Good for agencies' clients or genuinely separate brands.
Our guide to the WhatsApp Business Account (WABA) covers ownership, which matters most when a provider created the WABA for you.
What each number gets, and what they share
This is where teams get surprised. Adding a number does not add capacity across the board.
| Per number | Shared | |
|---|---|---|
| Display name | Yes, approved per number | |
| Quality rating | Yes, each number has its own | |
| Throughput | Yes, 80 messages per second by default | |
| Free service messages | Yes, 1,000 per month from Oct 1, 2026 | |
| Messaging limit (unique users outside the window, per 24h) | Portfolio level, across all numbers | |
| Templates | Per WABA, usable by its numbers | |
| Payment method | Per WABA | |
| Volume tiers | Aggregated across the portfolio |
The most important row is the messaging limit. Since October 2025, per Meta's messaging limits docs, the limit is set for the business portfolio and shared by all its phone numbers. A second number no longer doubles how many people you can reach with templates. If you are at 2,000, both numbers together are at 2,000. Our explainer on WhatsApp API messaging limits covers how to scale it.
Throughput is the opposite: it is per registered number, so a second number does double how fast you can push messages. Most businesses never get close to 80 per second; see WhatsApp API throughput if you do.
Good and bad reasons for a second number
Good reasons:
- Different markets. A local number per country looks familiar to customers and keeps regional teams separate.
- Different brands. Each brand needs its own display name and profile.
- Different jobs. A notifications number and a conversations number keep a burst of shipping updates from crowding the inbox your support team works in.
- Risk isolation for quality. Quality is per number, so a promotional campaign that draws blocks on one number does not drag down the quality of your support number.
Bad reason: spreading sends across numbers to dodge limits. The messaging limit is shared, so it does not work on Cloud API. On ordinary WhatsApp numbers, rotating numbers to send the same message to more strangers is exactly the pattern WhatsApp bans for. If you need more reach, fix list quality and consent; the guide to the WhatsApp quality rating explains what moves it.
Route inbound messages by number
Every Cloud API webhook names the number it is for. Inside entry[].changes[].value, the metadata object carries phone_number_id and display_phone_number. One app subscribed to several WABAs receives all of them on the same endpoint, so route on phone_number_id.
from fastapi import FastAPI, Request, Response
import hashlib, hmac, os
app = FastAPI()
APP_SECRET = os.environ["META_APP_SECRET"].encode()
ROUTES = { # phone_number_id -> team queue
"111111111111111": "support-india",
"222222222222222": "sales-india",
"333333333333333": "support-uae",
}
@app.post("/webhooks/whatsapp")
async def whatsapp(request: Request):
raw = await request.body()
sent = request.headers.get("x-hub-signature-256", "")
expected = "sha256=" + hmac.new(APP_SECRET, raw, hashlib.sha256).hexdigest()
if not hmac.compare_digest(sent, expected):
return Response(status_code=401)
body = await request.json()
for entry in body.get("entry", []):
for change in entry.get("changes", []):
value = change.get("value", {})
number_id = value.get("metadata", {}).get("phone_number_id")
queue = ROUTES.get(number_id, "unrouted")
for msg in value.get("messages", []):
await enqueue(queue, number_id, msg) # your job queue
for status in value.get("statuses", []):
await record_status(number_id, status)
return Response(status_code=200)
Keep an unrouted queue and alert on it. A number added in WhatsApp Manager but missing from your routing table is a silent black hole otherwise.
Reply from the number the customer wrote to
The reply must go out from the same phone_number_id the message arrived on. The customer service window is between the user and that specific number, and a reply from a different number reads as a stranger. Store the number id on the conversation and use it in the send URL: https://graph.facebook.com/v23.0/PHONE_NUMBER_ID/messages (use the current Graph API version from Meta's changelog).
import httpx, os
async def reply(conversation, text):
url = f"https://graph.facebook.com/v23.0/{conversation.phone_number_id}/messages"
payload = {"messaging_product": "whatsapp", "to": conversation.wa_id,
"type": "text", "text": {"body": text}}
async with httpx.AsyncClient() as client:
r = await client.post(url, json=payload,
headers={"Authorization": f"Bearer {os.environ['WHATSAPP_TOKEN']}"})
r.raise_for_status()
return r.json()["messages"][0]["id"]
As usernames roll out, some webhooks will carry a business-scoped user ID instead of a phone number. BSUIDs are scoped to the business portfolio, so they are stable across all numbers in it. Store them alongside wa_id.
Where Tenashi fits
Many teams with several numbers are not on the official API at all. They have a sales phone, a support phone and a branch phone, all ordinary WhatsApp or WhatsApp Business numbers, each with its own chats and groups. Tenashi links each one with a QR scan, and your team works all of them in one shared inbox with a CRM under every chat and roles that control who sees which number. See the multi-number WhatsApp inbox for the day-to-day side.
For developers, GET /api/v1/numbers lists your numbers with id, label, phone, status and connected. POST /api/v1/messages takes an optional from (a number's id or phone). Leave it out and Tenashi sends from the number that last talked to that person, which is usually what you want. Every webhook event includes the number it concerns, and number.disconnected tells you when one drops its link.
curl https://usetenashi.com/api/v1/messages \
-H "Authorization: Bearer $TENASHI_KEY" \
-H "Content-Type: application/json" \
-d '{"to": "+971501234567", "from": "+971500001111", "text": "Hi Omar, your Dubai showroom visit is confirmed for Saturday at 11."}'
The honest limits: limits apply per number, not pooled. Each number sends one message every 4 to 12 seconds, opens at most 50 new chats a day through the API, and a newly linked number warms up from 20 messages on day one. Each phone must stay active, because WhatsApp logs out linked devices after the phone is offline for a long time. Starter includes 1 number, Growth 3 and Scale unlimited, from $18/mo. For the official side of the picture, see the complete guide to the WhatsApp API.
Read the API docs · See every feature
FAQ
How many phone numbers can I have on the WhatsApp Business API?
New business portfolios can register two business phone numbers on Cloud API. Meta automatically raises the cap to 20 once the business is verified or reaches a messaging limit of 2,000 unique users per 24 hours. Numbers can sit in one WhatsApp Business Account or be split across several under the same portfolio.
Do multiple WhatsApp API numbers share the same messaging limit?
Yes. Since October 2025 the messaging limit is set at the business portfolio level and shared by all its phone numbers. Adding a number does not increase how many unique users you can reach with templates outside the 24-hour window. Throughput, quality rating and display name remain per number.
Can two numbers use the same WhatsApp message templates?
Yes, if they are in the same WhatsApp Business Account, because templates are created and approved at the WABA level. Numbers in different WABAs need their own copies of each template. That is one reason to keep numbers for the same brand under one WABA and separate brands in separate WABAs.
How do I know which number a WhatsApp webhook is for?
On Cloud API, each webhook change includes a metadata object with the phone_number_id and display_phone_number of the business number. Route on phone_number_id and reply from the same number. On Tenashi, every event includes the number object with its id, phone and label.
Can I use multiple numbers to send more broadcast messages?
Not on Cloud API, since the messaging limit is shared across the portfolio. On ordinary WhatsApp numbers, rotating numbers to message more strangers is a well-known ban pattern. Improve consent, targeting and quality instead. Use extra numbers for genuine separation: markets, brands or teams with their own customers.
More numbers should mean clearer ownership, not more chaos. See how Tenashi puts every number in one inbox, each with its own team and history.