How to choose a WhatsApp API provider (BSP)
You reach the WhatsApp Business API through a BSP. Here are the criteria that matter, from number ownership and template handling to your exit plan.
On the morning of a big promotion, an online retailer's WhatsApp line went quiet. Templates would not send; incoming messages never reached the dashboard. Meta was not the problem. The agency that set up the line two years earlier had ended its contract, and the number sat under the agency's Meta Business account. Getting it back took longer than rescuing the campaign.
You do not buy the WhatsApp Business API from Meta directly; you use it through a Business Solution Provider, a BSP. That choice is the foundation of your messaging infrastructure, and getting it wrong can leave your number, your templates and your chat history in someone else's hands. Below: what a BSP is, when to move from the app to the API, and the criteria worth checking.
What a BSP is and where it sits between you and Meta
A BSP is a business solution provider authorized by Meta for the WhatsApp Business Platform. Meta runs the infrastructure and the rules. The BSP builds the connection on your behalf, registers the number, submits template requests, carries message traffic and usually adds a dashboard or CRM integration on top. It is the layer between you and Meta: part intermediary, part operational partner.
That layer cuts both ways. Someone else handles registration, verification and infrastructure you would otherwise wrestle with alone, but with a third party in the middle it is easy to lose track of whose name critical assets sit under. We cover how the API works in what the WhatsApp Business API is; here the focus is which provider walks that path with you.
One clarification up front: Meta's policies, categories and limit rules change regularly, so what follows explains the mechanism, not fixed thresholds. For exact rules, check Meta's official documentation and ask your provider to confirm in writing.
App or API? Reading the switching moment
The WhatsApp Business app runs on a phone, sets up in minutes and is enough for a solo operator or a very small team. The API runs server side: any number of agents can work one number, messages land in your CRM, and automation and reporting become possible. The trade-off is setup effort, template discipline and a provider relationship to manage.
The switching moment announces itself the same way every time. People pass one phone around, nobody knows who answered which conversation, and order details vanish inside a thread. We compare the models line by line in WhatsApp Business app or Business API. If you are not at that threshold, postponing the BSP decision is a sound call.
The critical question: whose name holds the number and the WABA?
The first question when evaluating a provider is not price or feature count. It is this: will the WhatsApp Business Account (WABA) and the number be created under my own Meta Business account? Both belong under your business account, with the provider appearing as an authorized partner on it.
This is not a legal nicety; it is daily operations. With ownership on your side, switching providers becomes a permissions handover: the number stays yours, and your template history and quality rating travel with you. With ownership on theirs, leaving can mean losing the number, and reprinting every card, sticker and packaging insert carrying it is a cost no discount offsets.
The honest way to evaluate a provider is to picture the day the relationship ends, not the day it starts: if your number, your templates and your conversation history do not walk out with you, you bought a dependency rather than a service.
During onboarding, open Meta Business Manager, confirm ownership with your own eyes and keep the screenshot. Which number you use is a separate question; we cover the conditions in using virtual and landline numbers with WhatsApp Business.
Verification, display name and template support
The name a customer sees in the chat header is your first impression. Two things are in play: the display name and the green tick, the official business badge. The display name must follow Meta's naming rules while matching your brand; the green tick is its own application and review, covered in our guide to WhatsApp green tick verification. Ask who prepares these submissions and who runs the appeal when one is rejected.
Template approval is a process, not a one-time task
To message a customer first, you need an approved template, and category, language, variable structure and tone all shape the review outcome. We collected the rules for templates that pass in WhatsApp message template approval.
A capable provider gives you three things: drafting and submitting templates from the dashboard, rejection reasons in plain language, and an alert when a category changes. Reclassification shifts billing behavior and sending logic, so if the dashboard hides it, you learn from the consequences.
Transparency on delivery quality and quality rating
A message being sent is not a message arriving, and the gap between sent, delivered and read is the basis of every post-campaign analysis. Your provider should hand you those states as raw data, per message; aggregate counts alone are useless the moment something breaks.
Meta also maintains a quality rating for every number, with a messaging limit attached. When customers block or report your messages, the rating drops, the limit tightens and the number can eventually be restricted. A provider that surfaces this in near real time lets you pause and fix things.
- Status data: Confirm you can pull sent, delivered, read and failed states per message.
- Error codes: Make sure failed sends return the raw error code, because "delivery failed" alone tells you nothing.
- Quality alerts: Ask whether you are notified when the quality rating drops or the messaging limit changes.
- Limit management: The provider should explain which tier your sending limit sits in.
How conversation-based billing works
WhatsApp bills on conversations, not individual messages. When a conversation opens, a window stays open for a defined period and messages inside it count toward the same conversation. The category depends on who started it and what it contains: a marketing send and a customer-initiated support question land in different buckets.
What matters is architecture, not arithmetic. Five separate templates to one customer in a day produce a very different result from five messages inside one conversation. So ask: does the dashboard break costs down by conversation, and can I export billed line items as raw data? Ask to see in the contract which Meta model the provider's offer is built on, since those definitions get revised.
API maturity and webhook reliability
Every provider connects to the same platform, but not all expose everything it can do. List your requirements before onboarding and ask about each: media messages, interactive messages with buttons and lists, in-chat forms and booking flows, voice calling, channels and catalog integration. A capability you do not need today can become the reason you switch in six months.
Webhooks: the quiet criterion that decides everything
Inbound messages and status updates reach you through webhooks, and three things decide their quality: latency, retry behavior and signature verification. If your system goes unresponsive, does the provider retry or drop the event? When an event arrives twice, is there an ID that prevents duplicates? Test this in a sandbox before you sign.
Voice belongs here too. If a flow moves from chat to a call, team structure and infrastructure are planned together; we cover running a call center in house or outsourced separately.
Team management, roles and CRM integration
The reason teams move to the API is rarely technical. It is operational: several people working one number in an orderly way, which makes the provider's shared inbox as important as the API. Without assignment, handover, internal notes, tagging and role-based permissions, chaos grows with the team. We describe that structure in shared team inbox.
The second question is integration: a ready connector for your CRM, or everything built through the API yourself? Ready integrations are fast but sometimes shallow; the API is flexible but needs development capacity. On the Rocketly side, WhatsApp Business API, Instagram DM, Telegram, email and live chat land in one shared inbox, and conversations attach to the deal card. We walk through the logic in integrating WhatsApp chats into the CRM pipeline.
Data security, residency and support quality
In most architectures, message content passes through the provider's systems and is stored there for some period. That is personal data processing. The questions are straightforward: which country holds the data, how long is it retained, how are deletion requests handled, who are the sub-processors? Under GDPR and equivalent local regimes you need a processing agreement, and obligations shift, so have legal counsel confirm the arrangement before you go live.
Support is where marketing promises meet reality. In which languages and hours is it available, and when your number gets restricted, who do you reach? Rather than asking in a sales call, open a ticket during your trial and measure the real response yourself.
The exit plan: number portability and chat history
No provider relationship lasts forever, so talk through the departure scenario before you sign. How is the number transferred, how long does it take, does the line go dark during the move? Do templates go back through review? Can you export conversation history and media, in what format and by when?
If the answer is "of course, we'll sort it out," you have no answer. Ask for a concrete process, format and timeframe. We cover how dependency forms in vendor lock-in and data portability. For WhatsApp, the strongest protection is holding ownership from day one.
Deciding: scoring, a pilot and the usual mistakes
The healthiest way to compare providers is a weighted scoring table: assign a weight to every criterion, score each provider on the same scale, compare totals. Your requirements decide, not whichever demo was most polished.
| Criterion | Weight | What to check |
|---|---|---|
| Ownership | Critical | WABA and number under your Meta Business account |
| Template handling | High | Submission, rejection reasons, category alerts |
| Delivery transparency | High | Status data, error codes, quality warnings |
| Integration | High | Ready CRM connector or a mature API |
| Support | Medium | Language, hours, response commitment |
| Exit | High | Number transfer and data export |
Once the shortlist is down to two, run a real pilot: one number, a few templates through review, one campaign send, replies feeding into your CRM, and a deliberately broken webhook endpoint. An honest week-long pilot teaches more than a three-month demo cycle.
The three mistakes we see most
First, letting an agency or provider register the line under their own account: convenience on setup day, a painful bill on separation day. Second, running WhatsApp as a standalone channel without a CRM, so three people answer the same customer differently and nothing is measurable. Third, template indiscipline, because unmanaged sends erode your quality rating and shrink your limit.
Choose the right provider and WhatsApp stops being a messaging app and becomes a measurable sales channel: your number is yours, your templates stay tidy, your conversations live in the CRM. To run that from one place, create your Rocketly account and connect your WhatsApp line to the shared inbox.