Meta's WhatsApp Cloud API or Twilio: who should hold the number

Going direct to Meta's WhatsApp Cloud API and going through Twilio end at the same place: a number registered on Meta's platform, approved templates out, webhooks in. What differs is the layer between you and Meta, and that layer decides who is the customer of record, who files the paperwork, who answers when a number is blocked, and whose price list your bill follows. Choose a provider when you want one console and one invoice across channels; choose Meta directly when the number and the support relationship must be in your own name. The answer flips the moment a business tries to state, in writing, who owns the account.

What actually differs between the two paths

Meta hosts the platform and sells access to it. Twilio is an approved intermediary — a Business Solution Provider — with its own API, console, support desk and invoice. Messages travel over Meta's network and pass Meta's review; a provider does not remove that layer, it wraps it.

The comparison is not which SDK is nicer. It is how much of the platform you want to operate, and how much you want to rent.

Who owns the sender identity?

The number is registered against a WhatsApp Business Account, and that account carries the display name, the verification and the message history. Direct, the account is yours by construction. Through a provider it can still be yours — the good ones onboard you into an account you control — but it can also sit inside the provider's portfolio, where it is technically reachable and practically stuck.

Settle this before any code: whose name is on the business verification, and what happens to the display name if you leave. A number that cannot move is a number you do not own, whatever the contract calls it.

Who files the approvals?

Everything is reviewed by someone: the business documents, the display name, the phone number, and every template you send outside an open service conversation. Templates come back rejected in the platform's own vocabulary, and the difference between the paths is who translates it.

Direct, you read the rejection and learn the rules. Through a provider, a person usually reads it for you and rewrites the template. That is a real service and a real dependency: when their queue is slow, your launch is slow.

Who answers when something breaks at night?

Direct means documentation, a ticket and a status page. A provider means an account manager and a phone number — up to the edge of their platform. Anything inside Meta's review queue or delivery infrastructure is still Meta's to fix, and the provider will say so politely.

Decide which failure you are more likely to have. If a webhook your own server never acknowledged is the problem, no support desk fixes it. If a number restriction you do not understand is the problem, a human who has seen it before is worth paying for.

Who can change the bill, and how?

Meta charges for business-initiated templates by category and country, and has changed the shape of that billing more than once. A provider passes it through and adds a platform fee, or blends it into a rate of its own. Both are legitimate, and behave differently when Meta moves.

Ask about the mechanism, not the rate: is the provider's charge a margin on Meta's price, a flat subscription, or a per-message fee? Which part moves when Meta moves? Written down, that tells you what your bill does in a bad month.

Question	Meta Cloud API directly	Through Twilio
Who is the customer of record	you, by construction	depends on the onboarding
Who files documents and templates	your team	usually the provider
Who explains a rejection	platform documentation	a person, inside their queue
Who answers at night	tickets, status page	account support, up to their edge
How the bill is built	Meta's rate card	pass-through plus fee, or blended rate
What to verify on the vendor's page	template categories and review rules	whether the account stays yours

What has to run on your side?

Direct means you own the endpoint: an HTTPS route that verifies the signature on every webhook, stores message identifiers so a retry does not create a duplicate, rotates its token, and tracks which template versions are approved — ordinary server work that teams underestimate.

Through a provider you inherit their SDK and event format — faster to start and harder to leave, and anything built against their shape is throwaway the day you move.

How to decide, in order

1. Write down who will be the customer of record at Meta, by legal name, and who can prove it with a document.
2. List the messages you will send and who writes each one. A short transactional list makes the approval path less important; a long marketing-led one makes the provider's help worth its cost.
3. Ask both options the same questions in writing: who files a template appeal, what the escalation path is, and what happens to the number if you leave.
4. Test on the number you intend to keep. A sandbox hides every registration problem you will later meet.
5. Decide what your team can maintain: a webhook endpoint with logs, or a console with a support contract. An endpoint nobody watches fails silently.
6. Only then compare commercial shape, and mechanisms rather than headline rates.

Where this goes wrong

• Choosing the nicer dashboard. A console is the easiest thing to evaluate and the least important. Teams pick on it, then meet the ownership question months later.
• Going direct with nobody to operate it. Whoever had time builds the integration, then leaves, and messages queue with no alert reaching anyone.
• Treating template approval as a formality. Rejected copy stalls a launch, and the fix is editorial, not technical.
• Assuming the console is the truth. Delivery status lives on Meta's side, whatever the dashboard shows.
• Splitting the number across setups. One number cannot be in two places, and moving it is customer-visible.

When neither fits

If the real problem is that no order record exists to send a message about, neither path helps: the record comes first and the number is only its messenger. If one person answers the phone and volume is modest, the ordinary Business app with saved replies is still the honest answer.

Where this advice stops

This covers the choice of intermediary, not the wording of the messages or the migration of an existing chat history. It states no figures on purpose: template rates depend on category and country, provider fees are contractual, and any number printed here would be wrong before the page aged. Read the current rate card on each vendor's page, and your own contract as closely.

We build the order record and the endpoint behind the number, on either path; we resell neither, and we take no commission from the choice.