What is a WhatsApp Business Solution Provider, and what can it actually do?
A WhatsApp Business Solution Provider, or BSP, is a company Meta authorises to sell access to the WhatsApp Business Platform and to handle your account, number, and template plumbing. You are not choosing who delivers the message to the handset, because Meta does that. You are choosing who holds your account and prices the conversation.
That distinction sets a hard boundary on what any comparison can claim, so it is worth drawing before you read anyone's feature table, including ours.
Meta controls the parts that feel like they should differentiate a provider:
- Delivery to the handset. The Cloud API carries the message. A provider promising better WhatsApp deliverability is describing something it does not control.
- Template approval. Meta reviews every business-initiated template and every provider is subject to the same decision.
- The conversation fee, which depends on the template category and the destination country.
- Messaging limits, which scale per WhatsApp Business Account under Meta's own tiers.
What a provider genuinely owns is a shorter list, and it is the whole decision:
- Onboarding. Getting a number attached to a WhatsApp Business Account, verified, and live.
- The programmable surface. The API shape, the client libraries, the command line, and increasingly the tooling an AI agent can drive.
- Pricing. Whatever it adds on top of Meta's fee, and whether it says so on a public page.
- Observability. What you learn when a send fails, and how long that record survives.
- Portability. Whether you can move the number to another provider without losing the number or its history.
Every question below is about one of those five. If a claim you are weighing does not map onto one of them, it is probably a claim about Meta.
What does WhatsApp messaging cost, and who marks up Meta's fees?
Meta bills per conversation, and the rate depends on the template category and the destination country. That charge exists whichever provider you use, so the only variable a provider controls is what it adds on top and whether it publishes the number. Two questions separate the answers.
Is the conversation fee passed through at cost? Some providers pass Meta's fee through untouched and charge a flat monthly fee per number instead. Others fold it into a per-message rate, which makes the markup invisible. Neither model is wrong, and only one of them lets you check the arithmetic. Ask for the markup as a percentage, in writing.
Bird splits the two figures rather than merging them: the cost record on a message carries a passthrough amount alongside the platform amount, so the Meta portion and the Bird portion are separately visible after the fact rather than reconciled from an invoice.
Is the price list public at all? Published, self-serve WhatsApp pricing is less common in this market than you would expect, and where a provider does not publish rates, no amount of reading will produce a cost comparison. That is a procurement problem rather than a signal about price: a private rate can be competitive. But if your process needs a published number before it can proceed, find that out in week one rather than week six.
Two shapes to watch for in whatever you are quoted. Per-seat pricing suits a team staffing an inbox and reads expensively to a team sending programmatically, and the reverse is equally true. Throughput as a tier is the second: message throughput is sometimes sold as a plan rather than negotiated, which is worth knowing before you size a campaign.
How do I tell a real API from a dashboard with an API attached?
Almost every provider in this market has both a dashboard and an API, which is exactly why the distinction is hard to see from a features page. Four checks separate them, and they are worth running in this order: the first two take an afternoon of reading, the last two decide the integration.
Does the send API follow current conventions? WhatsApp's own Cloud API is JSON. A provider whose documented send path is form-encoded, or whose payload shape predates the Cloud API, is asking your team to learn a dialect rather than a protocol.
Is the base URL stable? Some providers give every account its own hostname. That is workable, and it does mean your configuration carries an account-specific host rather than one constant, which matters when you have environments to keep in step.
Are there SDKs, or only code samples? This is where a comparison most often goes wrong, in both directions. A documentation site that offers generated request snippets in seven languages is not the same as seven maintained client libraries, and the two look identical in a feature list. The check is specific and quick: look for published packages on the language's own registry, with a version and a recent release, rather than a list of language names on a marketing page.
Is the account programmable, or only the send? This is the newest axis and the one that separates providers fastest. Sending a message is table stakes. Creating a template, submitting it for review, buying and attaching a number, and reading back what happened are the operations that decide whether an agent or a script can run your WhatsApp channel without a human in the dashboard. For reference on our side, Bird's WhatsApp surface is 43 operations: all 43 on the command line and the MCP server, five on the typed SDKs, template authoring and submission included.
What happens when a message fails?
Sending is the easy half. The provider you will regret is the one that cannot tell you why a message did not arrive, and this is consistently the thinnest part of published documentation across the market. Three questions, in the order they will cost you.
What is the event vocabulary, and is it enumerated? Because BSPs relay Meta's Cloud API, inbound webhooks generally follow WhatsApp's own notification shape. A named, closed set of event types you can branch on beats a shape you infer from examples. Bird publishes seven WhatsApp event types, whatsapp.accepted, whatsapp.sent, whatsapp.delivered, whatsapp.read, whatsapp.received, whatsapp.failed and whatsapp.rejected, as members of a generated catalogue, and subscribing to a type outside that catalogue is rejected rather than quietly accepted.
Is a failure distinguishable from a rejection? A message the provider refused and a message Meta or the carrier dropped need different responses from your code. A single failure status cannot carry both, and finding that out in production means re-reading every handler.
Is the signing scheme documented? If you cannot verify that a webhook came from your provider, you are accepting delivery events from anyone who learns your endpoint. Ask for the signing scheme and the retry behaviour explicitly, because both are more often absent from a documentation site than present, and an absent answer is not the same as a missing feature.
Which provider shape fits which team?
Providers in this market are not competing for one buyer, which is why a single ranking would mislead you. Three shapes recur, and the useful exercise is matching the shape to who makes the decision and who maintains the integration, because those two people are often not the same.
A WhatsApp-only access layer. One channel, priced per number, often with the conversation fee passed through at cost, and thin on tooling. Frequently sold through a partner or reseller programme as well as directly. The right choice when WhatsApp is the only channel in scope and you have engineers. Bird vs 360dialog is that comparison in detail.
A finished WhatsApp workflow. A shared team inbox, a no-code chatbot builder, campaign scheduling, usually priced per seat. The API exists but the product leads with the inbox. The right choice when the requirement is who answers customer messages rather than what sends them, and no engineer is involved in the decision. Bird vs Wati covers that shape.
A multi-channel platform, which is what Bird is. WhatsApp alongside email, SMS and voice on one account, one API, and one delivery-event contract. The right choice when a second channel is already in scope or will be within the year, because consolidating later means a second onboarding, a second contract, and two sets of delivery data that do not join. This is the shape Bird sells, so these two comparisons carry the most weight on this page: Bird vs Twilio and Bird vs Infobip.
The honest test is which of the three you are. A team that will add SMS fallback within a year should not buy a WhatsApp-only provider on price, and a support team that wants an inbox next week should not buy an API and then build one.
What should I check before I sign?
Seven checks, ordered by what has cost teams the most when skipped. The first three are answerable from public pages in an afternoon. The last four need the provider on a call, and the answers are worth having in writing before a contract rather than after one.
- Can this number be WhatsApp-enabled at all? Not every number can, and finding out after purchase is an expensive way to learn. Bird exposes this as a precheck on the command line and the MCP server (
whatsapp.numbers.precheck) so the answer arrives before the money does. - Who owns the WhatsApp Business Account? If it is the provider's rather than yours, leaving later is a migration rather than a configuration change. Ask what leaving looks like before joining.
- Is the conversation fee passed through at cost, and if not, what is the markup?
- Is the event vocabulary enumerated, and are webhooks signed? The weakest published area in the market, and the one most likely to be answered with a shrug.
- What does template approval look like when it goes wrong? Meta decides, so the difference between providers is whether you can read the rejection reason and submit a new version without recreating the template.
- What is the throughput ceiling, and is it a tier or a negotiation?
- Does a second channel exist on the same account? If not, price the second onboarding into the comparison now rather than discovering it next year.
Where a provider is already on your shortlist, the per-provider detail lives in the comparisons rather than here: Bird vs the WhatsApp providers collects them.