Jul 09, 2026

Do You Need a WhatsApp BSP? When to Go Direct on the Cloud API

No, you do not need a WhatsApp Business Solution Provider to get API access. Meta hosts the Cloud API and you can build against it directly. Here is when a provider earns its fee and when it does not.

Send bulk WhatsApp messages the safe way
Import a CSV, personalize each message, and broadcast on the official WhatsApp Business API. Free tier: 500 messages a month.
Start free →

Short answer: No. You do not need a WhatsApp Business Solution Provider to access the WhatsApp Business API. Meta hosts the Cloud API itself, and any business with a developer can register a number, hold an access token, and send messages directly. What a provider sells is not access. It is onboarding, an inbox, template management, CRM sync, and someone who answers the phone when a template gets rejected. Whether that is worth paying for depends on whether you have engineers and how much you plan to send.

This question gets a lot of bad answers because most of the pages ranking for it are published by the providers themselves. "You must go through an authorized BSP" is a sentence that sells software. It stopped being true a while ago, and it is worth understanding exactly when it stopped, because the history explains why so much of the advice you will read is stale.

Why people think a BSP is mandatory

Until fairly recently, it was. The original WhatsApp Business API was the On-Premises API, and it was genuinely gated. You could not sign up for it. A business had to go through a partner who hosted the containerized API on your behalf, submitted your phone number for approval, and resold you capacity. That partner was the Business Solution Provider. The acronym BSP dates from that era and so does the belief that you cannot get in without one.

Meta retired the On-Premises API on October 23, 2025. The final version, v2.63, expired, and messages sent to or from business numbers still registered to it stopped being delivered. Everything now runs on the Cloud API, which Meta hosts. There is no container to run, no partner to host it, and no gatekeeper standing between you and a phone number ID.

Meta's own documentation has moved on too. The current partner docs describe two categories, Solution Partner and Tech Provider, and the phrase "Business Solution Provider" does not appear in them. Meta defines a Solution Partner as a Meta Business Partner that provides "a full range of WhatsApp Business Platform services to other businesses (clients), such as messaging services, billing, integration support, and customer support." Note what is absent from that list: permission to use the API.

Can I use the WhatsApp API without a BSP?

Yes. The Cloud API is a REST API hosted by Meta. You create a Meta Business Account, create a WhatsApp Business Account inside it, register a phone number that is not already active on WhatsApp, and Meta issues you a phone number ID and an access token. You POST to a messages endpoint to send, and Meta POSTs to an HTTPS endpoint you own when something arrives. That is the whole system. Nothing in it requires a third party.

The catch is not access. It is everything around access. Here is what the direct path actually asks of you.

  • An HTTPS endpoint that stays up. Meta sends a GET verification challenge, then POSTs every inbound message, button reply, and delivery status. If your endpoint is down, those events are gone.
  • Token rotation. The token you generate in the developer console for testing is not the one you run production on. System user tokens, permissions, and expiry are a real piece of setup work.
  • Template lifecycle management. Every business-initiated message must use a template Meta approved in advance. Templates get rejected, get quality ratings, and get paused. Somebody has to watch that.
  • An interface for humans. A REST API is not a place for your support agent to answer a customer. You will build an inbox or buy one.
  • Media handling, retries, rate limits, and error codes. The unglamorous half of any messaging integration.

None of this is hard for a competent backend team. All of it is a sprint or three that your team is not spending on your actual product.

When going direct is clearly right

Go direct if you send a small, predictable volume of transactional messages and you already have engineers. The classic case is authentication codes. If WhatsApp is one of three channels your app can deliver a one-time passcode over, you do not want a subscription and a dashboard. You want an endpoint. Meta charges you per delivered authentication template and nothing else, and the integration is a few hundred lines.

Go direct if you are a software company embedding WhatsApp inside your own product for your own customers. At that point you are the provider. Adding a middleman between your code and Meta's code adds latency, cost, and a dependency you cannot debug.

Go direct if your volume is enormous and your requirements are simple. Per-message platform fees that look trivial at ten thousand messages look absurd at ten million. Do the arithmetic before you sign anything with a per-message component.

When a provider earns its fee

Pay for a provider when the constraint is time rather than money. Most teams that need WhatsApp need it this quarter, for a use case that is already agreed, and the engineering roadmap is full. Embedded signup, template submission, a working shared inbox, and a first delivered message inside an afternoon is worth real money against a sprint you do not have.

Pay for a provider when conversations have to reach your CRM. This is the piece nobody wants to build twice. Matching an inbound number to the right contact, writing the thread to the timeline, firing the follow-up, and writing delivery receipts back to the record is a genuine integration project against every CRM you touch. Our WhatsApp CRM integration page walks through exactly what syncs and what it costs you to build it yourself.

Pay for a provider when template quality is a business risk. A paused template on a Black Friday morning is expensive. Providers who do this all day know what wording gets rejected, watch quality ratings, and flag a template before Meta does something about it. Meta will not do that for you.

And pay for a Solution Partner specifically if you want one invoice. This is the one place where Meta's partner tiers matter commercially. Solution Partners can extend a credit line and bill you directly for API usage. Tech Providers cannot, so you attach your own payment method to Meta and get two bills. Neither is better. They are different procurement stories, which is worth knowing before your finance team finds out the hard way. We break the distinction down in Solution Partner vs Tech Provider.

What a provider cannot do for you

Here is the part the sales calls skip. No provider can change what Meta will deliver. If a vendor's US pitch is built around promotional broadcasts, walk away, because Meta's documentation states that WhatsApp "does not currently deliver marketing template messages to WhatsApp users with United States phone numbers." That pause started on April 1, 2025 and no resume date has been announced as of July 2026. It sits at Meta's delivery layer, so it applies to every provider identically.

What still delivers to US numbers is worth memorizing, because it is what your integration should actually be built on. Utility templates go through: order confirmations, shipping updates, appointment reminders, quotes, renewal notices. Authentication templates go through. And any free-form reply you send inside the 24-hour customer service window, which opens when a customer messages you first, delivers and is free. Service conversations have been free for every business since November 1, 2024.

Nor can a provider skip Meta's account requirements. A Meta Business Account starts limited to 20 WhatsApp Business Accounts and 2 registered phone numbers, raisable to 20. New business portfolios start at a messaging limit of 250 unique customers per rolling 24 hours, moving to 2,000, then 10,000, 100,000, and unlimited as you verify the business and demonstrate quality. Any provider claiming it can lift those for you is describing something Meta controls, not something they do.

The cost question, answered properly

Two meters run at once, and conflating them is how you get overcharged. Meta charges per delivered template message, priced by category and recipient country, and charges nothing for non-template messages or for calling the API. The provider then charges for its software, and the model varies enormously. Twilio publishes a per-message platform fee of $0.005 inbound or outbound, on top of the Meta fees it passes through. 360dialog charges a flat monthly fee per registered phone number and markets no markup on Meta rates. Others charge per agent seat, which quietly taxes you for hiring support staff.

Before you sign with anyone, ask for a sample invoice with Meta's message cost on one line and the provider's fee on another. A vendor that will not separate them is marking up your messages and betting you never check the rate card. Our WhatsApp Business API pricing page covers the Meta side so you have something to compare against.

How to decide in about ten minutes

Answer three questions honestly. First: does a backend engineer have three weeks free in the next two months? If no, buy. Second: do conversations need to land on a contact record in a CRM your team already uses? If yes, buy, unless that CRM is the product you are building. Third: at your projected twelve-month volume, what does a per-message platform fee add up to, and is that more than a flat plan? Run the number, not the vibe.

Most teams that ask "do I need a BSP" are really asking "am I about to get ripped off." The answer is that you are not required to use anyone, which means every provider has to justify its fee on the software rather than on gatekeeping. That is a much better negotiating position than the one the vendor pages want you to think you are in. When you do compare vendors, our guide to choosing a WhatsApp business solution provider lays out the five questions that separate the serious ones from the resellers.

One last practical note for teams going direct. Once you have utility templates firing off real events, the events themselves usually live in other systems: a shipping platform, an ERP, the tool where your purchase order status actually gets updated. The WhatsApp side is rarely the hard part. Getting a clean, trustworthy event out of the system of record is. Solve that first and the messaging almost writes itself.