Messaging Accounts & messaging_account_id

Under Meta's new account model, a business phone number can have more than one Messaging account. Billing, spend limits, and analytics belong to the Messaging account, not to the phone number, so every send must resolve to exactly one Messaging account. The messaging_account_id parameter on the Messages API names that account in the cases where Meta cannot work it out on its own.

What a Messaging Account Is

A Messaging account holds message templates, the payment method, analytics, and webhook subscriptions. Existing WABA IDs became Messaging account IDs in phase 1 of Meta's rollout, so the waba_id you already store, and entry[].id in webhooks, is a Messaging account ID.

• The business or a partner can own a Messaging account.
• Each partner working with a business gets its own Messaging account, which keeps templates, billing, and metrics separate between partners.
• A business can also use one Messaging account per billing currency on the same number.
• In Meta Business Suite, Messaging accounts are listed under Settings → Accounts → Messaging accounts.

Partners can list the Messaging accounts shared with their business portfolio with Meta's Client WhatsApp Business Accounts API (GET /<BUSINESS_ID>/client_whatsapp_business_accounts).

When to Send messaging_account_id

Send messaging_account_id whenever the access token you send with has messaging access to more than one Messaging account on the business phone number in the request.

The access token is the only thing in a send request that identifies you, so Meta resolves the Messaging account from it. If the token reaches exactly one Messaging account on that number, Meta selects it and you do not need the parameter. If it reaches two or more, nothing in the request says which one you mean, so name it.

• The rule is about ambiguity, not about your role. It applies the same way to a partner sending on a client's number and to a direct developer sending on their own.
• A WhatsApp account holds exactly one phone number, so "more than one Messaging account on the phone number" and "more than one Messaging account on the WhatsApp account" are the same condition.
• Embedded Signup creates one Messaging account per partner app, so in the common partner case a token reaches a single Messaging account per number. Meta advises reasoning about the token rather than the app: the token's asset permissions decide which Messaging accounts you can send from.

Common Cases

These are typical, not a complete list:

If You Leave It Out

Do not rely on Meta to resolve an ambiguous request. When your token reaches more than one Messaging account and you leave out messaging_account_id, Meta may bill and attribute the message to a Messaging account you did not intend, or reject the request. Send the parameter whenever ambiguity is possible, even while it is still optional.

When It Becomes Required

paid_messaging_account_id Is Deprecated

paid_messaging_account_id is a deprecated, backward-compatible alias for messaging_account_id. Move to messaging_account_id by December 31, 2026. After that date Meta plans to remove the alias in a future Graph API version.

If a request carries both, messaging_account_id wins and paid_messaging_account_id is ignored.

Example Request

Add messaging_account_id to the request body to charge a specific Messaging account:

curl -X POST "https://graph.facebook.com/v25.0/<PHONE_NUMBER_ID>/messages" \
  -H "Authorization: Bearer <CUSTOMER_OWNED_META_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "messaging_product": "whatsapp",
    "to": "<WHATSAPP_USER_PHONE_NUMBER>",
    "messaging_account_id": "<MESSAGING_ACCOUNT_ID>",
    "type": "template",
    "template": {
      "name": "<TEMPLATE_NAME>",
      "language": { "code": "<LANGUAGE_CODE>" }
    }
  }'

The parameter sits next to the normal message fields. Everything else in the request is unchanged.

Templates Belong to One Messaging Account

Templates belong to the Messaging account they were created in and are not shared with other Messaging accounts on the same number. To use the same template in several Messaging accounts, create it in each, or copy it with Meta's Template Migration API.

Copied templates restart at baseline quality rating and messaging tier, and need roughly 2–4 weeks to ramp up again. Template management endpoints (/<WABA_ID>/message_templates) are unchanged and address the Messaging account. See Templates.

Payment Methods

Each Messaging account has its own payment method, independent of other Messaging accounts and of ad accounts. It is attached in Meta Business Suite or by API.

Check which payment method is attached:

curl -X GET "https://graph.facebook.com/v25.0/<MESSAGING_ACCOUNT_ID>?fields=primary_funding_id" \
  -H "Authorization: Bearer <CUSTOMER_OWNED_META_TOKEN>"

If primary_funding_id is missing from the response, the Messaging account has no payment method and cannot send paid messages. See error 131042.

Who attaches it depends on the partner type:

• Businesses that work with a Tech Provider or Tech Partner add their own payment method to the Messaging account.
• A Solution Partner shares its line of credit with the business during onboarding. A client-owned Messaging account that carries a Solution Partner's credit line cannot be shared with another partner.

Delivery Receipts

Delivery receipts go back to the app that sent the message, whichever Messaging account was charged. The payload format is unchanged. If you bill your own customers by delivery receipt volume, query primary_funding_id on the Messaging account you sent from to see which line of credit was charged.

Dualhook Boundary

• A Dualhook connection maps to one Messaging account: the WABA ID shown on the connection.
• Runtime API sends go out with the connection's own authorization, which normally reaches only that Messaging account, so you can leave messaging_account_id out. Dualhook does not add it. If you send it, or paid_messaging_account_id, the value must be the connection's WABA ID; any other value is refused with 403.
• Dashboard and Runtime API template actions apply only to the connection's Messaging account. Dualhook does not offer the Template Migration API.
• Dualhook does not read, show, or attach payment methods, and the Runtime API's WABA read returns no funding fields. Check the payment method in Meta Business Suite on the Messaging account under Settings → Accounts → Messaging accounts.
• Dualhook cannot see or manage other partners' Messaging accounts on the same number.
• If you call Meta directly with your own token, whether you need messaging_account_id depends on that token, not on Dualhook.