What Is a WhatsApp BSP and How to Choose One: Official Provider

What Is a WhatsApp BSP and How to Choose One: Official Provider

A WhatsApp BSP (Business Solution Provider) is the company that sits between your business and the WhatsApp Business Platform, Meta's official API. It handles the technical connection, the dashboard, support and, usually, billing. To choose well, the most important factor is not the price on the pricing page. It is who owns the account, whether you can leave and take your number with you, and what gets recorded for every conversation.

Key takeaways

• The BSP is the bridge between your company and the official WhatsApp API, and the quality of that bridge affects customer service, auditing and the cost of switching.
• The account and the number should belong to your company, inside your own Meta business portfolio, and not to the provider.
• Portability must be checked before you sign: number, templates, history and integrations.
• Support and logs matter most when something goes wrong: an undelivered message, a rejected template, a falling number quality rating.
• Choosing a BSP is a reversible decision if you insist on a clear contract, your own access and a small pilot before you scale.

What a BSP does in practice

The official WhatsApp API is not an app you install on a phone. It is a platform that receives and sends messages through software integration. To use it, a company needs a Meta business account, a phone number, approved templates for outbound messages and a technical entry point to receive incoming messages. A BSP delivers much of this already set up.

What usually comes in a provider's package:

• Onboarding: help registering the number, connecting the account and completing verification steps.
• Support interface: a dashboard where your team can reply, assign conversations and look up history.
• Sending and receiving by API: the provider exposes endpoints and webhook notifications for your system or AI agent.
• Template management: creating templates, submitting them for approval and tracking their status.
• Billing: passing through what Meta charges for conversations and messages, plus the provider's own fees, when there are any.
• Support: a channel to resolve connection failures, blocks and usage questions.

Meta has used different names for its partner ecosystem over time (solution provider, solution partner, tech provider). What matters to a buyer is the function: someone between you and the platform, with more or less control over your account. Always confirm the current model in Meta's official documentation.

BSP, official API and the WhatsApp Business app: what is the difference

Three things are often confused. The WhatsApp Business app is the free phone version, designed for small businesses that reply manually. The official API is the platform for integrating systems, automating flows and serving customers with several people or with AI agents. The BSP is the company that, in practice, gives you access to that API.

There are also unofficial solutions, which simulate WhatsApp Web or use methods that break the platform's rules. They look simpler at first, but they expose the number to being blocked and leave the company with no recourse. If your goal is to run AI in a stable way, it is worth reading about how to avoid a banned number when automating with AI.

A simple decision rule:

• Manual service, low volume, one or two people: the WhatsApp Business app is usually enough.
• Several people replying, CRM or ERP integration, outbound messages with templates: the official API through a provider.
• An AI agent replying to customers, with decision records and handoff to a human: the official API, with extra attention to logs and permissions.

For the full integration design, the guide on how to integrate AI into your company's WhatsApp covers the technical steps.

Who should own the account and the number

This is the criterion that weighs the most and appears the least in sales proposals. In Meta's structure, the WhatsApp Business account is tied to a business portfolio, formerly called Business Manager. The question is: whose portfolio is it?

The healthy setup looks like this: the account sits in your company's portfolio, verified with your own details (company registration number, legal name), and the BSP receives delegated access to operate it. You appear as administrator and the provider as a partner with defined permissions. If the relationship ends, you revoke the access and the account stays yours.

The risky setup is the opposite: the account is created inside the provider's portfolio, the number is registered in the provider's name and you are just a customer inside their structure. In that case, leaving can mean starting from scratch, losing history, approved templates and the reputation your number has built.

Direct questions to ask before signing:

• Will the WhatsApp Business account be created in my business portfolio?
• Who appears as administrator? Will I have my own administrator access?
• Will the number be registered in my company's name?
• If I end the contract, what happens to the account, the templates and the history?

Business verification with Meta is a step that often shapes this setup. The step-by-step is in Meta business verification for the WhatsApp API. Doing it with your own company's details is part of keeping ownership.

Portability: how not to get locked in

Portability is the ability to change providers without interrupting service or losing what you have built. It has four layers, and each one should be asked about separately.

First layer, the number. It is generally possible to migrate a number between providers, but the procedure has technical requirements, such as handling the two-step verification PIN. Ask whether the provider documents this process, whether it cooperates when you leave and how much downtime to expect. Confirm the current steps in Meta's documentation, because operational rules change.

Second layer, the templates. Outbound messages depend on approved templates. If the account is yours, they stay with it. If not, they may be lost. For how to design those templates and the consent base behind them, see WhatsApp outbound messages: templates, opt-in and best practices.

Third layer, conversation history. Many providers store conversations in their own database. Ask whether there is an export in an open format, with date, sender, content, attachments and delivery status, and whether it has a cost or a waiting period. Without an export, your history is held hostage by the contract.

Fourth layer, integrations. If your CRM, your ERP and your AI agent talk to a proprietary format from the provider, switching means rewriting everything. Prefer providers that expose a documented API and clear webhooks, and isolate that dependency in a layer of your own system. That way, changing BSP means swapping an adapter, not redoing the project.

Support and logs: what to ask for before you need them

Support is only tested when something breaks: the number drops in quality, a template is rejected, messages stop arriving or the company receives a warning from Meta. At that moment, what counts is the speed and competence of whoever answers.

Points to evaluate:

• Channels and hours: does support work in your language, during hours that fit your operation?
• Escalation: is there a path to someone technical, or only a first-level agent?
• Service level agreement: are response times by severity written into the contract?
• Incident communication: does the provider warn you about outages and platform changes?
• Experience with your case: does it already run support, billing or scheduling flows similar to yours?

On logs, the reasoning is the one behind observability in general: you need to be able to reconstruct what happened from records. The OpenTelemetry observability primer explains well why logs, metrics and traces complement each other. For WhatsApp, a useful minimum includes:

• A record of every message received and sent, with timestamp and identifier.
• Delivery and read status, and the reason for failure when there is one.
• A record of webhooks received and retry attempts. Stripe's webhook documentation describes webhook delivery and verification logic, as an example of good practice.
• A record of who accessed the dashboard and what they changed.
• For AI agents: which instruction was used, which decision was made and when a handoff to a human happened.

Also ask how long logs remain available and whether you can access them without opening a ticket. Remember that conversations contain personal data. Under Brazil's LGPD, your company remains responsible for the processing and the provider acts as processor. It is worth checking the contract, the data processing clauses and the guidance from ANPD, Brazil's data protection authority. If the provider uses subcontractors or stores data outside Brazil, that should be declared.

Selection checklist and an illustrative scenario

Use this list to compare two or three providers with the same questions. Mark what is written in the contract, not just what was said in the meeting.

• The account sits in my company's business portfolio, with my own administrator.
• The number is registered in my name and there is a documented migration procedure.
• Templates and history are exportable, with a defined format and timeframe.
• Billing separates what belongs to Meta from the provider's own fees, with no hidden costs to leave.
• There is a documented API and webhooks, with authentication and permission control.
• Each person's access is limited to what is necessary. The OWASP authorization cheat sheet helps define roles.
• Logs exist for messages, delivery and access, with retention stated.
• Support has a channel in my language, escalation and contractual response times.
• The contract describes the provider's role in processing personal data.
• It is possible to start with a small flow before committing to volume.

Illustrative scenario: an electrical supplies distributor wants to answer quote requests on WhatsApp, with an AI agent that collects the items and hands the conversation to a salesperson. It receives two proposals. In the first, the provider creates the account in its own portfolio, offers a full dashboard and says nothing about export. In the second, the provider asks the distributor to create and verify its own portfolio, receives delegated access, delivers API documentation and describes how to export conversations. The second seems to require more work at the start, but it leaves the company with decision-making power. Months later, if volume grows or the provider's service disappoints, switching is a planned migration, not a restart.

How to apply this: map, limit, pilot, hand over

The method we use for WhatsApp AI projects helps take the BSP choice out of the realm of opinion.

• Map: describe the current flow, who replies, which messages are most frequent and what data passes through the channel. Without this, you cannot know which features and logs you actually need.
• Limit: define what data the provider and the agent can see, what actions the agent can take and when the conversation goes to a person.
• Pilot: sign up for one real, small flow, with logs on and a success metric agreed in advance. The article on how to measure an AI automation pilot shows how to define those criteria and the decision gates.
• Hand over: at the end of the pilot, operations, access and documentation stay with your team, and the decision is to expand, adjust or stop.

The pilot also works as a test of the provider: how long onboarding took, how support reacted to a real problem, whether the data export actually worked. Those answers are worth more than any sales presentation.

Frequently asked questions

What is a BSP on WhatsApp? It is a Business Solution Provider, a company that provides access to the official WhatsApp Business Platform API and surrounding services such as a dashboard, support, template management and billing. It does not own WhatsApp and does not replace your company's relationship with Meta. The more of the account you control, the better your position.

Do I need a BSP to use the official WhatsApp API? In practice, most companies use a provider because it reduces technical and operational work. There are direct access options for teams that have engineers and want to take on hosting, monitoring and support, but that increases internal responsibility. Confirm the current options in Meta's documentation and assess whether your team can maintain that setup.

Can I switch BSPs and keep the same number? Generally yes, as long as the number is registered in a way that allows migration and you follow the steps Meta requires, including handling the two-step verification PIN. The risk lies in contracts that leave the account under the provider's control. Ask before signing and request the procedure in writing.

What should I look at first when comparing providers? Start with account ownership and portability, because they define your cost of leaving. Then evaluate logs and support, which determine your ability to solve problems and be accountable. Only then compare dashboard features and fees, once you know what each proposal really delivers.

Sources

• OpenTelemetry: observability concepts
• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP: authorization guidance
• Stripe: webhook delivery and verification