← All posts
Guide

WhatsApp Account Model Evolution: What the WAAC and Messaging Account Split Means in 2026

Meta’s WhatsApp Account Model Evolution splits the old single WhatsApp Business Account (WABA) into two layers: a WhatsApp Account (WAAC) that holds identity and the phone number, and a Messaging Account that holds message templates, billing, and webhook subscriptions. The practical effect is that one phone number can now be shared across multiple partners or direct API integrations, while templates, throughput, and billing stay isolated per Messaging Account — and a deprecated API parameter must be migrated by December 31, 2026.

Key takeaways

  • The old WABA is being separated into a WAAC (phone number, business profile, username, catalog) and a Messaging Account (templates, billing, webhook subscriptions) — two containers with different jobs.
  • One phone number can now be shared across multiple partners or direct API integrations, but the number’s throughput capacity is shared, not stacked, across them.
  • Message templates are not shared across Messaging Accounts; each partner or integration recreates and re-approves its own.
  • A phone number’s quality rating follows the number (the WAAC), not the partner, so switching BSP does not reset reputation.
  • The rollout runs in three phases through 2028, and the deprecated paid_messaging_account_id parameter must migrate to messaging_account_id by December 31, 2026.

What the WhatsApp Account Model Evolution changes

For most of the Cloud API’s life, a single WABA held everything: the phone number, the business identity, the message templates, the webhook subscriptions, and the billing. Meta’s Account Model Evolution breaks that single container into two so that identity and messaging operations can scale independently.

The new split looks like this:

LayerWhat it holdsWhy the split matters
WhatsApp Account (WAAC)Phone numbers, business usernames, business profile information, product catalogsIdentity and the number stay stable even if the messaging operator changes
Messaging Account (keeps the old WABA ID)Message templates, billing and payment methods, webhook subscriptionsTemplates, billing, and delivery config are scoped to one operator’s integration

The most consequential change is at the phone-number level. Meta now states that “clients and direct developers can share their phone number with multiple partners,” and describes the result as “one trusted phone number works across all integrations.” Under the older model, a number was effectively bound to one BSP or one direct Cloud API integration, and Meta documented that “you can share a WABA with up to two partners.” The new architecture generalizes that, which is why the change is architectural rather than a cosmetic relabeling.

This is separate from the billing changes landing on October 1, 2026. The service vs utility message classification and the service-message charge tracking guide explain what becomes billable and how to measure it. The Account Model Evolution is about who owns the number and the templates, not what each message costs.

What gets shared and what stays isolated when a number is multi-partner

The multi-partner number is the part most teams get wrong, because “shared number” implies shared everything. The official documentation draws three clear boundaries.

Throughput is shared, not stacked

Meta states that “when multiple partners share a phone number, they share the phone number’s throughput capacity.” A number with a given messages-per-second limit does not get N times that limit because N partners send through it; the partners draw from one pool. Plan capacity at the number level, not the partner level. The general throughput documentation sets the per-number defaults and auto-scaling tiers that this shared pool draws from.

Templates are not shared across Messaging Accounts

Meta states that “templates belong to the Messaging Account in which they were created and are not shared across Messaging Accounts.” If three partners each need an order-confirmation template on the same number, each Messaging Account carries its own copy and each passes Meta’s template review independently. The current per-account template cap of 250 templates applies per Messaging Account, not per number.

Quality rating follows the number

A phone number’s quality rating (green, yellow, red, based on user blocks and reports) is an attribute of the number — the WAAC — not of the partner operating it. That has a double-edged implication: a strong number carries its good standing across partners, but a number that one partner degrades through poor sending behavior affects every partner sharing it. Coordinate sending discipline across partners rather than assuming each partner’s reputation is walled off.

The 2026-2028 rollout timeline

Meta documents the migration in three phases, each tightening what developers must change.

PhaseWindowWhat happensWhat you must do
Phase 1 — General availabilityH2 2026Meta handles the account migration automatically, separating WAAC and Messaging AccountFor most multi-account setups, no code change is required; verify the split in your dashboard
Phase 2 — New Graph API versionH1 2027The newest Messages API version requires messaging_account_idUpdate API calls that target a Messaging Account to pass the new identifier
Phase 3 — Mandatory transitionH1 2028All APIs that target a phone number ID must use WAAC IDs insteadMigrate any phone-number-ID-based routing to WAAC IDs

A tighter deadline sits inside Phase 1. Meta states that developers must “migrate to messaging_account_id by December 31, 2026, after which it is planned for removal.” If your integration still sends the deprecated paid_messaging_account_id parameter, treat that date as the hard cutover, not the Phase 2 window.

A migration checklist for Solution Partners and Tech Providers

This migration belongs to the partner or provider that owns a Cloud API integration, not to a business that only uses the WhatsApp Business app. If you maintain that integration, run through this before each phase boundary.

  1. Inventory every API call that names a WABA, phone number ID, or paid_messaging_account_id. A shared launcher or shared config can hide a deprecated parameter until a phase cutover breaks it.
  2. Confirm the WAAC / Messaging Account split in your dashboard. Verify which templates, webhook subscriptions, and billing methods landed in which Messaging Account after the automatic Phase 1 migration.
  3. Migrate paid_messaging_account_id to messaging_account_id before December 31, 2026. Do not wait for Phase 2; the parameter removal is its own deadline.
  4. Reconcile template ownership per Messaging Account. If multiple partners need the same template on a shared number, recreate and re-approve it in each Messaging Account rather than assuming inheritance.
  5. Model throughput at the number level for shared numbers. Sum the expected send rate across all partners on a number and confirm it fits the number’s shared capacity.
  6. Document quality-rating coordination. Because the rating follows the number, agree on sending-volume and opt-in discipline with every partner sharing it.
  7. Prepare phone-number-ID routing for the Phase 3 WAAC-ID switch. Tag every code path that routes by phone number ID so the H1 2028 cutover is a controlled migration, not a surprise.

For teams still deciding whether they need the official Cloud API path at all, the three WhatsApp inbound paths and the BSP platform comparison frame that decision before you invest in an account-architecture migration. The WhatsApp Coexistence guide covers the related question of running the Business app and Cloud API on the same number.

Where UnifyPort fits

UnifyPort does not operate inside Meta’s Account Model Evolution. It does not manage WAACs, Messaging Accounts, Meta template approvals, Cloud API permissions, or Meta billing. If your product needs a number shared across multiple official partners, or needs to migrate paid_messaging_account_id before the deadline, the official Cloud API path is the correct one and this migration is mandatory for the integration owner.

UnifyPort fits a different requirement: connecting an ordinary WhatsApp account and receiving supported inbound messages as one normalized event stream. A WhatsApp inbound message arrives as a standard message.received event, the same envelope used for Telegram, LINE, TikTok, Zalo, and X:

{
  "id": "evt_7c41f0b2a9",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-31T09:24:18Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM",
      "type": "text",
      "text": "Can your team check my shipment before closing today?",
      "direction": "inbound",
      "sent_at": "2026-07-31T09:24:16Z"
    }
  }
}

When the webhook endpoint has a signing_secret, every delivery includes X-Device-Timestamp and X-Device-Signature, and your receiver verifies the HMAC-SHA256 signature against the raw request body before processing — documented in the webhook delivery and signature reference. Supported replies use POST /v1/messages.

That path is deliberately separate from the official account architecture. It does not grant WAAC identity, Meta template approval, Cloud API permissions, or any of the multi-partner privileges the Account Model Evolution governs. Keep the two paths explicit: the official migration changes how a number and templates are owned inside Meta’s platform; an unofficial inbound interface changes where ordinary-account messages land in your system.

Limitations and trade-offs

Use the official Cloud API and complete the Account Model Evolution migration when you need approved outbound templates, official campaign tooling, Click-to-WhatsApp attribution, Meta-native analytics, a number shared across multiple certified partners, or a BSP’s managed compliance workflow. The WAAC / Messaging Account split exists to make those official workflows cleaner.

An unofficial interface cannot supply any of those Meta platform privileges. It cannot make a number eligible for multi-partner sharing under Meta’s model, approve a template, or move a Messaging Account’s billing and webhooks. Its narrower benefit is a standard inbound interface for ordinary messaging accounts and a normalized queue across several platforms — a different decision from how to structure a Cloud API integration.

The phase dates (H2 2026, H1 2027, H1 2028) and the December 31, 2026 parameter deadline are time-sensitive. Recheck Meta’s official Account Model Evolution page before each cutover, because Meta rolls these documents forward without visible version stamps.

FAQ

What is the WhatsApp Account Model Evolution?

It is Meta’s separation of the old WABA into a WAAC (holding the phone number and business identity) and a Messaging Account (holding templates, billing, and webhook subscriptions), so that one number can be shared across multiple partners or direct integrations.

Can one WhatsApp phone number be shared across multiple BSPs now?

Yes. Meta states that clients and direct developers can share a phone number with multiple partners. The number’s throughput capacity is shared across them, and each partner’s templates live in its own Messaging Account.

Are message templates shared across Messaging Accounts?

No. Meta states that templates belong to the Messaging Account in which they were created and are not shared across Messaging Accounts. Each partner recreates and re-approves the templates it needs.

When do I have to migrate paid_messaging_account_id?

Meta states that developers must migrate to messaging_account_id by December 31, 2026, after which paid_messaging_account_id is planned for removal.

Does switching BSP reset a WhatsApp number’s quality rating?

No. The quality rating follows the number (the WAAC), not the partner. A number’s standing carries across partners, for better or worse, so sending discipline must be coordinated across everyone sharing the number.

Next step

If you own a Cloud API integration, start the migration with the official Account Model Evolution guide and retire paid_messaging_account_id before December 31, 2026. If your requirement is ordinary-account inbound messaging instead, review the WhatsApp provider authorization guide and the provider message support matrix to evaluate that separate path.

Sources