WhatsApp Cloud API or a BSP: when building it yourself pays off

Sooner or later, someone looking at the WhatsApp invoice asks the obvious question. Why are we paying Twilio, or Gupshup, or WATI, when Meta's Cloud API is open to any business that signs up? It is a fair question. The honest answer depends on one number most teams have never worked out: what the provider adds each month, set against what it would cost you to build and run the parts the provider runs for you.

Meta's own fees do not change with the route. A marketing template to an Indian number costs $0.0118 at Meta whether you send it yourself or through a provider. The pricing post covers those fees and what changes on 1 October 2026. This one is about the layer on top.

I work on both sides of this line. At Acefone I work on Interaction Hub, one inbox where agents handle phone calls, WhatsApp messages and WhatsApp calls together. On my own I run PostEngage, a WhatsApp and Instagram automation product that talks to Meta's APIs itself. Neither could be a thin layer over somebody else's inbox. Most businesses are not in that position, and for them the arithmetic usually points the other way.

What you are actually comparing

Start with what does not change. Meta bills per delivered template, and from 1 October per service reply, at the rate for the recipient's country. The limits are Meta's too. A new business portfolio can message 250 unique people outside a customer service window in a 24-hour period, and climbs through 2,000, 10,000 and 100,000 to unlimited as it proves quality, according to Meta's messaging limits page. The one place a provider helps there is "partner-led verification", which Meta lists as one route to the 2,000 tier. Throughput is also Meta's: the Cloud API supports up to 80 messages per second per number by default, with an automatic upgrade to 1,000 for numbers that already message 100,000 unique users a day.

So a provider does not buy you cheaper messages or bigger limits. None of the six I checked advertise a discount on Meta's fees. They pass them through or add to them. What a provider sells is three things:

• Plumbing. Webhooks, retries, template management, media handling, and usually an inbox your support team can log into.
• Somebody to call. Meta does not offer a commercial uptime SLA for the Cloud API. 360dialog's cheapest plan includes 24/7 support with a four-hour response target and escalation to Meta. Direct, your escalation path is a developer support ticket.
• Onboarding. Business verification, number registration and display name approval are fiddly the first time and easy the fifth. Providers have done them hundreds of times.

The question is whether those three are worth what you pay for them, at your volume.

How the providers charge

These are from each provider's own pricing page, checked on 12 September 2026. Where a provider prices in rupees, I have compared it with Meta's rupee rate card: ₹0.8631 for marketing and ₹0.115 for utility and authentication on Indian numbers.

The three shapes behave very differently as you grow. A per-message fee scales with every bubble in both directions, so it hurts most where Meta's own rates are low. A per-number fee does not scale with volume at all. A markup scales with your Meta bill, so it hurts most in marketing-heavy, expensive markets.

Two things stand out. Twilio charges for inbound messages as well as outbound, so a support-heavy business pays it on every message a customer types. And in India, where Meta's utility rate is $0.0014, Twilio's flat $0.005 is more than three times Meta's fee on every utility message and every OTP.

What going direct actually means

Sending a WhatsApp message through the Cloud API takes one HTTP call, and that call is where the tutorials stop. A production integration is two pipelines, and both are yours.

Here is the checklist I would scope for one business on one or two numbers. The hours are my estimate, not a quote. They are also the defaults in the calculator, so change them there if your team is faster or slower.

1. Webhook receiver, 24 hours. Meta signs every request, and you check it by computing an HMAC-SHA256 of the payload with your app secret and comparing it with the X-Hub-Signature-256 header, per Meta's endpoint guide. The endpoint needs a valid TLS certificate; self-signed ones are not supported. Answer 200 quickly and do the work later, because anything other than a 200 is retried "with decreasing frequency until the request succeeds, for up to 7 days", and Meta's webhook overview says plainly that "these retries can result in duplicate webhook notifications". Payloads can be up to 3 MB.
2. Send pipeline, 32 hours. A queue in front of the API, a rate limiter per number, retries with backoff for errors worth retrying, and a dead-letter queue with an alert for the ones that are not. Every send needs an idempotency key, or a retry becomes a second message and a second charge. Idempotency and backpressure are the two properties that decide whether this pipeline survives a bad day.
3. Statuses and billing reconciliation, 16 hours. Store every sent, delivered, read and failed status, along with the pricing object Meta attaches, so you can predict the invoice before it arrives.
4. Templates, 24 hours. Business-initiated messages outside the 24-hour window must be approved templates. Meta's templates overview says review "can take up to 24 hours", and templates can later be paused or disabled based on quality. You need a way to author them, submit them, track their status and map variables from your data.
5. Opt-in and opt-out, 12 hours. Meta's opt-in rules require that people know they are opting in and to which business, and that you "provide clear instructions for how people can opt out of receiving specific categories of messages, and honor these requests". That means a consent record, a way to capture "stop", and a check before every business-initiated send.
6. Media, 12 hours. Media URLs expire after five minutes and media IDs in webhooks expire after seven days. If a customer sends a photo of a damaged parcel, you download and store it when it arrives, not when an agent opens the chat on Monday.
7. An inbox, 120 hours. Threads, agent assignment, canned replies, and a visible timer for the 24-hour window so agents know when a free-form reply is no longer allowed. This is the biggest line and the thing most providers are really selling.
8. Embedded Signup, 40 hours, only if you onboard other businesses. Meta's Embedded Signup is how tech providers let their customers create WhatsApp accounts from inside a product. A business sending its own messages does not need it.

The first seven come to 240 hours. At $40 an hour, a round number rather than a benchmark, that is $9,600 once. Upkeep is the part people leave out. I have put it at 16 hours a month plus $50 of hosting and monitoring, which is $690 a month.

Upkeep is not optional. In PostEngage, every call to Meta, every Stripe event and every delivery webhook is a job with an explicit retry policy, a dead-letter queue and an alert, because messaging failures are invisible until they are expensive. A template gets rejected and a campaign silently does not go out. A webhook stops arriving and nobody notices until a customer complains. A rate limit tightens and the queue grows. Someone has to own those alerts, and those hours are the monthly figure.

Run your own numbers

The defaults describe a US fintech that mostly sends login codes through Twilio: 200,000 authentication templates, 60,000 utility templates, 5,000 replies, and 8,000 inbound messages a month. Change the provider to see how each pricing shape reacts to the same traffic, and untick anything on the build list you would not need.

On the defaults, Meta's share is $881 a month and Twilio adds $1,365. Running it yourself would cost $690 a month after a $9,600 build, so the build pays back in 15 months. Switch the provider to Gupshup and the answer becomes "never", because Gupshup's $273 is less than the upkeep alone.

Five businesses, priced

The same arithmetic, run for five shapes of business on Meta's 1 October rate card. The payback column compares going direct with staying on Twilio, using the same $9,600 build and $690 a month upkeep.

The UK desk is the useful surprise. Its Meta bill is large because UK rates are high, but Twilio's flat fee is small next to them, and the $350 it adds is less than the cost of running the integration yourself. Expensive markets make percentage markups painful and per-message fees look cheap. Cheap markets do the opposite.

The Indian brand at ten times the volume is the other extreme. Twilio's $8,000 a month would pay for the build in under two months. Even Gupshup's $1,600 pays it back in 11. At that size a flat-fee provider like 360dialog costs $56.80 a number, which is why large senders in cheap markets tend to end up on flat-fee plans or direct.

The break-even volumes are worth remembering. With the build and upkeep above, going direct pays back within two years once you pass about 218,000 messages a month on Twilio, sent plus received, and within one year past 298,000. On Gupshup the same points are about 1.09 million and 1.49 million. On 360dialog Regular, you would need 13 numbers before the plan fees even match the upkeep.

When to go direct anyway, and when not to

Cost is only half the decision. Some reasons to build do not show up in a payback column.

The messaging is the product. PostEngage is an automation product built on Meta's APIs. Putting a provider between it and Meta would mean paying twice and debugging through someone else's logs. If you are a platform onboarding other businesses, you are the provider, and Embedded Signup is on your list.

The inbox has to do more than WhatsApp. Interaction Hub puts a phone call, a WhatsApp chat and a WhatsApp call in one thread for one agent. No provider's inbox does that for your stack. If you go this way, the lesson I would pass on is to put the interaction event schema under contract tests on day one. Every channel produces events, every service reads them, and a field renamed in one place breaks three others quietly.

You need control over failure. Retry policy, what counts as a duplicate, when a message is too stale to send: a provider makes those choices for you. Most of the time their choices are fine.

And the reasons not to build are just as real. If nobody on the team will own the alerts, a direct integration becomes a slow outage. If support needs an inbox next week, buy one. If you send a few thousand messages a month, no build pays back.

There is also a middle path. A flat-fee provider that exposes the raw API gives you most of the economics of going direct, while they handle onboarding and escalation to Meta. You can build your own inbox on top and move the number later. Meta's migration guide says a migrated number keeps its display name, quality rating, messaging limits, Official Business Account status and any high-quality approved templates. Other templates have to be submitted again, and numbers move one at a time.

The short version

Meta's fees are the same whichever way you send, so the only thing to compare is what your provider adds against what running it yourself would cost. Per-message providers like Twilio get expensive fast, especially in cheap markets and on inbound-heavy support traffic. Flat per-number plans almost never lose on cost. Percentage markups sit in between and follow your Meta bill.

Going direct is a real system: a signed webhook receiver that tolerates duplicates, a send pipeline with retries and a dead-letter queue, template and opt-out handling, media storage and an inbox. Build it when the calculator says it pays back inside a year, or when the messaging is your product. Otherwise, the cheapest win is usually a provider whose pricing matches your traffic.