Scaling past one number: when and how a growing product splits across WABAs

One phone number works fine until throughput ceilings or one bad campaign's quality damage start bleeding into every other use case sharing it. The real question isn't "can we add a number" — it's what boundary to split along.

Advanced

4 min read

The signals that one number has stopped being enough

Two distinct pressures push a product toward more than one number, and they're worth telling apart because they call for different fixes. A throughput pressure — routinely brushing against the messaging-limit tier ceiling covered in an earlier lesson — is a capacity problem; requesting a tier increase or simply waiting out the automatic escalation may solve it without adding anything. A risk-isolation pressure — OTP delivery, order confirmations, and promotional marketing all flowing through the same number — is a design problem no tier increase fixes, because it means one bad marketing send can drag down the quality rating that OTP deliverability depends on.

The default good boundary is use case, not customer or region

The instinct to split "one number per customer" or "one number per country" usually isn't the boundary that matters. What actually matters is keeping traffic with very different risk profiles off the same number:

Bad split (shared risk):     one number handles OTP + shipping updates + marketing
Better split (isolated risk): number A - Authentication + Utility (transactional)
                               number B - Marketing (promotional, opt-in only)

A marketing send that tanks quality rating on number B has zero effect on number A's ability to deliver a login code. Splitting by geography or by customer segment is a legitimate later reason to add more numbers, but it doesn't address the actual quality-contamination risk the way a use-case split does.

Same WABA, more numbers — vs. more WABAs entirely

Adding a second phone number to an existing WABA is the lighter-weight move: it reuses that WABA's already-approved templates immediately, since templates are WABA-scoped, not number-scoped. Standing up an entirely separate WABA is heavier — every template needs independent submission and independent review, even ones that are wording-identical to an already-approved template elsewhere in the same Business Portfolio.

Add a number to the SAME WABA   -> templates already usable, fastest path
Create a SEPARATE WABA           -> full template resubmission required,
                                     but full quality-rating isolation too

The tradeoff is exactly the isolation the previous section described: numbers under the same WABA share billing and Business Portfolio context but are still individually quality-rated, so even a same-WABA split gets most of the isolation benefit without the resubmission cost — a separate WABA is worth it mainly when the use cases need to be organizationally distinct too (different teams, different App, different webhook handling entirely).

The routing logic a backend needs once there's more than one number

Every inbound webhook payload includes metadata.phone_number_id, identifying which of the App's connected numbers an event belongs to — the same webhook URL serves all of them, per an earlier lesson. Sending code needs the mirror image: a lookup from "which use case is this" to "which phone_number_id sends it."

config = {
  transactional: { phoneNumberId: "1234...", wabaId: "aaa..." },
  marketing:      { phoneNumberId: "5678...", wabaId: "bbb..." },
}

function send(useCase, payload) {
  const { phoneNumberId } = config[useCase]
  return callSendApi(phoneNumberId, payload)
}

Hardcoding a single phoneNumberId constant anywhere in application code is the thing that has to be found and removed before a second number can go live — worth structuring as a lookup from day one, even with only one number configured, since retrofitting it later means an audit of every call site.

Migrating a live number without downtime

Meta supports migrating an already-active, already-verified phone number from one WABA to another (even across Business Portfolios in some cases), rather than starting that number's history and quality rating over from zero. This matters for any restructuring done after a number already has real traffic and an established quality rating — Business Verification must be complete on both the source and destination WABA, and a payment method configured on both, before migration is available.