WhatsApp BSP vs Cloud API in 2026: A Control and Exit Scorecard

Decision: choose a WhatsApp Business Solution Provider (BSP) or Solution Partner when you need a managed inbox, onboarding, integration support or an operational team you cannot provide yourself. Choose direct Cloud API access when you can own the webhook, inbox, credentials, monitoring, incident response and product changes. Do not make “direct is cheaper” or “a partner owns the number” your decision rule. Meta’s public material now describes a split between the WhatsApp Account for phone numbers and a Messaging Account for templates and billing, and says account sharing can support multiple Tech Providers and Solution Partners. That makes number control one part of the exit question; it does not prove that inbox history, templates, event logs or a vendor’s routing configuration will move with it.

The WhatsApp solution-provider vs Cloud API comparison introduces the two deployment approaches. This companion adds a buyer-run control and exit scorecard: before signing, establish who holds each asset, what the provider adds, what the monthly bill includes, and whether a replacement can send and receive messages without losing the service workflow.

The short answer for a Swiss SME

A Cloud API is an API access and messaging route; it is not, by itself, a staffed shared inbox, a customer-support process, a CRM connector, a content approval workflow or an on-call service. A provider can supply some or all of those components, but “BSP” is not one uniform technical or commercial package. Ask what the provider is officially registered to do, which product they actually operate, which components are theirs, and what your staff would still have to run.

Meta distinguishes Tech Providers and Tech Partners from Solution Partners. Its partner page describes Tech Partners as third-party developers building value-added solutions on the platform; Solution Partners offer end-to-end solutions that can include integration and customer support, and only Solution Partners can extend a line of credit for payment. Meta’s page also says businesses can work with multiple Tech Providers and Solution Partners through account sharing. The role label is useful context, but it is not a service-level agreement: it does not tell you response times, export rights, recovery responsibilities or the price of a particular vendor’s software. Meta’s partner-role description is the primary source for those program distinctions.

The buy-side question is not simply “Cloud API or BSP?” It is: which combination of Meta access, inbox software, integration work, account administration and support leaves the business able to operate and exit? A direct connection can still depend on a third-party CRM or inbox. A partner-led arrangement can still leave your business with the phone number and administrative access. Compare the real deployment architecture and contract, not the label on a sales page.

The user question behind this decision

For 23–30 October 2026, the French Search Console property showed 12 impressions, 0 clicks and average position 21.3 for the query “quelle plateforme choisir pour whatsapp business api ?” on the source page used for this guide. This is one query-page row from one property and one seven-day window. It signals a concrete comparison question; it is not a count of 12 people, a survey of Swiss businesses or evidence that the search was made by voice. It does not establish market size or likely revenue. The query is the reason to answer the platform choice directly instead of repeating broad WhatsApp marketing tactics.

The source page already contains a quick answer, an explanation of the operational model, a checklist, common mistakes and a seven-day action plan. Its useful next step is to make the buyer compare ownership and exit conditions after reviewing Meta’s current role and account information. That is the gap addressed here: a reusable register that turns a provider comparison into assets, owners, evidence and a go/no-go decision.

First separate the products and roles

The WhatsApp Business App, the Business Platform and an inbox vendor are not interchangeable. The Business App is a product people can use through its app interface. The Business Platform exposes business messaging capabilities that can be integrated through approved interfaces. A provider may build its own software over the platform, resell access to its own inbox, perform onboarding, manage some account tasks or connect another system. Ask the salesperson to draw the actual message path: customer message, Meta platform, webhook or vendor connector, inbox, agent, CRM, reply and status event.

The phrase “Cloud API” refers to a platform interface hosted by Meta; it does not imply that Meta operates your service desk. The phrase “BSP” is commonly used for providers in this ecosystem, but Meta’s public partner material currently uses distinct labels such as Tech Provider, Tech Partner and Solution Partner. A vendor may be a software provider, an implementation partner, a Solution Partner, or a combination. Confirm the entity in the agreement and the role it performs in your setup. If the vendor says “we are official,” ask which Meta role, account permissions and technical functions that means in the production architecture.

Draw two boxes for a first-pass diagram:

DIRECT ROUTE
Customer ↔ WhatsApp Business Platform ↔ your webhook/integration ↔ your inbox/CRM
                                      ↘ your monitoring and support

PARTNER ROUTE
Customer ↔ WhatsApp Business Platform ↔ partner connection ↔ partner inbox/CRM
                                      ↘ partner support + your named escalation owner

This diagram is deliberately incomplete: a real system can include a CRM, customer-data platform, analytics service, automation vendor, contact-centre platform, cloud hosting and several subprocessors. Extend it until every system that receives message content, metadata or attachments is visible. Do not decide from a simplified diagram that leaves out where agents actually read and answer customers.

What changed in the account-control discussion

On 16 June 2026, Meta’s developer event listing described an evolved WhatsApp account model that separates a WhatsApp Account (WAAC) for phone numbers from a Messaging Account (PMA) for templates and billing. The listing says this architecture can let a single phone number be shared across multiple partners and integrations while keeping billing separate. The listing is a primary Meta source for the stated model, but the page does not publish a complete migration manual, eligibility matrix or guarantee that every account has the same controls. Treat it as a reason to inspect your own Business Manager and test the workflow, not as proof that every vendor connection is freely interchangeable. Meta’s WhatsApp Account Model Evolution session page describes the change.

This affects how you should ask about “number ownership.” The phone number and business identity may be administered separately from templates and billing in the evolved model. A number shared across integrations may reduce one kind of dependence: a business may not need to treat the number as inseparable from one partner’s entire stack. It does not establish that the customer-service inbox, assignment rules, historical threads, read states, attachments, analytics, automation, templates, payment methods, API credentials or service logs are shared or portable. Those are different assets with different owners.

The public Meta page is an event description, not a transcript. It gives the session topic and summary, but does not expose a full transcript in the page text reviewed for this article. Accordingly, this guide does not claim to have independently observed every screen shown in the video. If your decision depends on WAAC/PMA migration eligibility or a specific shared-number path, ask the provider to demonstrate it in your own business portfolio using a test number, show current asset IDs and permissions, and provide the relevant current Meta documentation before production cutover.

The control-and-exit scorecard

Use this register with each provider and your internal team. Mark a row green only when a named person can perform the action in the production account or run a documented recovery test. “We can help” is not evidence; a signed role, screen share, export sample or test receipt is evidence. Mark yellow when the plan exists but has not been tested, and red when no owner or proof exists. These colors are a review convention, not a measured reliability scale.

Control area	Ask before signing	Evidence to request	Red flag
Phone number and business identity	Which account contains the number, who is admin, and can the business add or remove a partner?	Account IDs, named admin roles, tested partner change	Vendor alone controls the number or refuses to identify the account structure
Messaging account, templates and billing	Who creates, edits and approves templates? Which account owns billing and payment method?	Current account map, template export/sample, billing example	“Number ownership” is presented as proof templates and billing are portable
Webhook and API credentials	Who creates tokens, rotates secrets, receives events and owns retries?	Credential owner, token rotation procedure, redacted webhook test	Shared personal token, no rotation owner, no event-delivery evidence
Inbox and conversation history	Where do staff read messages? Can the business export threads, attachments, labels, assignments and audit events?	Export sample and re-import test in another workspace	“History is in the number” without a tested export
CRM and customer records	Which fields are copied, retained or synchronized, and who resolves duplicates?	Field map, retention schedule, reconciliation sample	The only customer record is inside a vendor’s inbox
Monitoring and incidents	Who detects a failed webhook, rejected template or degraded inbox, and who is on call?	Escalation ladder, incident contact, test alert	Support ends at a help-centre link and no internal owner exists
Pricing	Which Meta message charges, provider fees, seats, setup, integrations and support are included?	One-month sample invoice and scenario-based price sheet	A single “per conversation” number hides charges
Exit and transition	What can be exported, how long does an export take, and what is the cutover and rollback sequence?	Contract clause, portable archive, test plan, named operator	No exit owner or no way to preserve service history
Privacy and suppliers	Which legal entity processes data, which sub-processors are involved, and what data is retained?	Data-flow diagram, processing terms, locations, deletion statement	Provider cannot list systems that receive message data

Decision matrix: direct, partner or pause

Your operating reality	Likely route	Gate that must pass
Engineering owner, monitoring, inbox plan, tested webhook recovery	Direct Cloud API can fit	A named person owns tokens, events, logs, incidents and customer response
Need a ready shared inbox, agent roles, onboarding and support	Managed provider or Solution Partner can fit	Contract specifies service scope, escalation, export, account administration and all fees
Can build integration but need an add-on or CRM connector	Tech Provider or Tech Partner may fit	You know who owns each account action, failure and future update
Need multiple integrations on one business number	Assess current WAAC/PMA controls and permissions	Demonstrate the account, templates, billing and revocation behavior; do not rely on a general announcement
No one owns the inbox, privacy review, event failures or exit	Pause production	Assign owners and prove minimum controls before inviting customers

A matrix cannot decide how much support your team values. State service hours, language coverage, incident severity, response expectations, onboarding help and who can authorize production changes. A provider’s support offer, described at a high level by Meta’s Solution Partner category, is not a vendor-specific service level. Ask for the actual commitment in the contract, including holiday coverage and what happens if Meta rather than the provider is unavailable.

Compare the whole cost, not the API line

Meta’s current pricing page says the platform charges on delivered messages, with rates varying by market and message category. It lists marketing, utility, authentication and service categories and publishes rate cards. A cost estimate therefore needs a destination market, message category, expected delivered volume and period. Do not compare a provider’s software quote with a Meta message rate as if they cover the same service. Meta’s pricing page is the primary source for the category and charging model; recheck the live rates when you build a budget.

Build a monthly cost model with separate lines: Meta platform messages; provider platform or handling fee; agent seats; inbox or automation add-ons; onboarding and integration; hosting or monitoring you operate; support tier; migration work; and internal time for message review, template maintenance, incident handling and data reconciliation. Include fixed and variable charges. Ask for a sample invoice for your own message mix, not only a list price for one category. Record assumptions such as country, delivery status, service window, categories and whether the quoted amount includes taxes.

Direct API is not “free.” The provider fee may be zero, but engineering, hosting, security, monitoring, inbox software, training and support still cost time or money. A managed provider is not automatically expensive. It may replace internal build and maintenance work, but the buyer should verify what has been bundled and whether a charge is per message, contact, active seat, account, integration, campaign or support request. A sensitivity range is more honest than one forecast: model low, expected and high activity, then vary the share of messages in each category.

Map each asset to its real owner

A useful buyer-created asset is a one-page WhatsApp Asset and Exit Register. The business fills it in during discovery and attaches evidence. It should list the phone number and WAAC (if present), PMA or other messaging account (if present), WABA IDs during any transition, account admins, payment method, template owners, API app, token service, webhook endpoint, inbox provider, CRM integration, event logs, staff accounts, data exports, subprocessors, service contacts and deletion process. For each line record the business owner, vendor, current permission, export format, recovery path, renewal dependency and evidence date.

The register separates business identity from service delivery. The business might control its number while the vendor controls the only inbox configuration and reporting export. A contractor might create the webhook while no one on staff knows where the signing secret is rotated. Marketing may own templates while finance receives the bill. The number may remain available during a vendor change while customer histories and assignments are not. Without a register, each stakeholder can truthfully say “we own WhatsApp” while describing a different layer.

The FTC’s business data-security guide recommends taking stock of information, keeping only what is needed, protecting it and disposing of it securely. That is U.S. guidance rather than a statement of Swiss legal requirements, but its inventory-first sequence is useful when asking what a messaging provider stores and how the business can delete or export it. For Swiss or cross-border obligations, identify the relevant laws and obtain appropriate local privacy advice; this article is an operational buying guide, not a legal opinion. The FTC business guide provides the cited inventory and minimization guidance.

For API exposure, OWASP notes that APIs can expose application logic and sensitive information such as personal data, and are a target for attackers. Translate that general risk into vendor questions: can each integration be limited to required scopes? Can tokens be rotated without an outage? Are inbound event signatures checked? Are logs redacted? Can former staff and vendors be revoked promptly? What is retained in backups? OWASP’s API Security Project is a general technical security reference, not a WhatsApp implementation checklist.

Three operating examples

A small retailer with no engineering on call. The owner needs a staffed inbox during opening hours, a reliable way to assign messages and help when templates are rejected. A managed provider is often the practical starting hypothesis, because direct API would transfer operational work to a team that has not committed to own it. The retailer should still control a business admin account, know where the number and account records sit, export customer history and test how the provider responds to an urgent outage. If the vendor cannot show those controls, convenience has a hidden continuity cost.

A software company with an existing support platform. The company already operates a ticketing system, receives signed webhooks and has an on-call engineer. Direct API may avoid paying for a second inbox and preserve routing in the existing support workflow. That fits only if agents can see customer context, the API connection is monitored, retries are safe and someone owns template and policy changes. A direct route that produces messages but loses replies in a queue is not a successful integration.

An agency or group with several brands and service providers. The business may care about distinct billing, templates, phone-number access and partner scopes. Meta’s partner page says account sharing can support multiple Tech Providers and Solution Partners, and its 2026 account-model session describes separate number and messaging-account layers. That does not eliminate the need to test how one partner’s permissions affect another, how billing is divided and what the customer can revoke. Use a test portfolio and a non-customer number to prove the exact behavior. Keep a separate business-level record of consent, opt-outs, customer requests and campaign approvals rather than treating a vendor’s dashboard as the sole source of truth.

McKinsey’s 2021 platform-transformation guidance argues that build, integrate and partner decisions should follow the business strategy and that platform participants should understand dependency on the platform operator. It is general platform advice, not an evaluation of WhatsApp providers, but it supports a sensible order: specify the customer-service outcome and strategic control points first, then choose the integration arrangement. McKinsey’s platform-transformation article is the consulting perspective used here.

A vendor demo that tests control instead of polish

Ask the finalist to perform a scripted demonstration with a test number and synthetic messages. Do not send real customer data during discovery. The test should show: a customer message arriving; the exact event reaching the provider or your webhook; a staff member being assigned; the staff member replying; the status event being recorded; a template being edited and approved; a token being revoked; a second partner being added or removed if multi-partner use is part of the design; a failed endpoint recovering; and an export of the message record. Record account ID, who performed each action, timestamp, visible product, present data and what the export contains.

Keep the demo focused on observed transitions. “We support WhatsApp” is a claim. “Here is the test message, here is the event, here is the assignment, here is the response status, and here is the export” is evidence. If a provider cannot demonstrate a step live, classify it as unverified rather than assuming the feature exists. If the provider relies on customer success staff to perform a restricted operation, record that dependency and the escalation time.

Use the same script against every finalist. Ask one person from customer support, one from IT or the integrator and one from finance or operations to observe. The purpose is not a market benchmark; it is to find which parts of the business will carry the ongoing work. After the demo, the business should be able to explain what stops working if the vendor is unavailable tomorrow and what it can restore without that vendor.

Reusable tool: a lightweight exit-readiness gate

The following Node.js check is a small, original working asset for a vendor review. It does not inspect Meta, the provider, the network or the legal basis for processing. It checks whether a human has recorded the minimum ownership and recovery evidence in a JSON register. It returns a review state, not a compliance certificate and not proof that the export is complete. Replace the example paths with your own records and have the responsible people verify each field.

Save as check-wa-exit.mjs:

import { readFile } from 'node:fs/promises';

const file = process.argv[2] ?? './whatsapp-exit-register.json';
const register = JSON.parse(await readFile(file, 'utf8'));
const required = [
  'businessOwner', 'phoneNumberAdmin', 'messagingAccountOwner',
  'templateOwner', 'billingOwner', 'apiCredentialOwner', 'webhookOwner',
  'inboxProvider', 'historyExportEvidence', 'recoveryTestDate',
  'incidentContact', 'subprocessorList', 'contractExitClause'
];
const missing = required.filter(key =>
  typeof register[key] !== 'string' || register[key].trim() === ''
);
const untested = ['historyExportTested', 'credentialRevocationTested', 'recoveryTested']
  .filter(key => register[key] !== true);
const status = missing.length || untested.length ? 'PAUSE' : 'READY_FOR_REVIEW';
console.log(JSON.stringify({ status, missing, untested }, null, 2));
if (status === 'PAUSE') process.exitCode = 2;

Create whatsapp-exit-register.json with values you have actually checked:

{
  "businessOwner": "Operations lead",
  "phoneNumberAdmin": "Business admin group",
  "messagingAccountOwner": "Finance and messaging admin",
  "templateOwner": "Customer support manager",
  "billingOwner": "Finance lead",
  "apiCredentialOwner": "Integration service account owner",
  "webhookOwner": "Platform engineer",
  "inboxProvider": "Named provider and product",
  "historyExportEvidence": "Ticket reference and export location",
  "recoveryTestDate": "2026-11-01",
  "incidentContact": "Named primary and backup",
  "subprocessorList": "Contract appendix location",
  "contractExitClause": "Agreement section reference",
  "historyExportTested": false,
  "credentialRevocationTested": false,
  "recoveryTested": false
}

Run it with:

node check-wa-exit.mjs ./whatsapp-exit-register.json

The sample intentionally leaves the three test flags false, so the expected result is PAUSE and exit code 2. That is the safe default: a document reference is not the same as a tested recovery. Once a test passes, record who did it, which environment and account were used, what was excluded, and where the evidence is stored. Avoid placing raw API tokens, phone-number personal data or message content in this register; store controlled references, not secrets.

The tool does not distinguish an unavailable feature from an unperformed test. The reviewer must do that. If history export is impossible, keep historyExportTested false and document the alternative archive or the business decision to accept loss. If a provider offers a manual migration, record the operator, expected duration, format, cost and conditions. If an action is only available through a support ticket, that is an operational dependency even if the provider agrees to help.

Why this is more useful than a vendor score out of ten

A single score compresses distinct failure modes. One provider can have a polished inbox and weak export; another may give the business account administration but no after-hours support. A weighted score can hide a red control behind a high product score. The register instead separates facts the buyer can verify. It can be reused at procurement, renewal and after a change to the API, CRM, payment method or provider.

The state labels are intentionally conservative:

• PAUSE means at least one required owner, evidence reference or successful test is missing. It is not a judgment that the provider is unsafe; it means the buyer has not demonstrated readiness.
• READY_FOR_REVIEW means the minimum record is complete and named tests are marked successful. It does not mean approval. Privacy, security, architecture, legal, budget and customer-service owners still review the evidence.
• Approved for production is a separate decision made by your organization under its change process. This script never prints that status.

A useful register is deliberately boring. It gives the next operator a place to begin when a person leaves, a vendor changes its product, a billing account expires or a message stops arriving. Keep it under version control or in a controlled document repository with an owner and review date. Use a redacted example for training; access to message content and credentials should be governed separately.

Run an exit rehearsal before it is urgent

A practical rehearsal can happen in a sandbox or with a non-customer number. Agree on a time window, freeze configuration changes, capture current account IDs and permissions, save a known-good export, and list the services that will be affected. Have the provider show the supported transition steps, but let the business owner perform the actions that are meant to remain under the business’s control. If a test cannot be run without disrupting customers, use a test number or a cloned integration and document what remains unproven.

Exercise at least four paths. First, provider unavailable: can the business find its incident contact, recent message events and fallback support channel? Second, credential compromise: can the owner revoke and replace credentials without putting a shared password in chat? Third, integration failure: can the team distinguish a Meta-side rejection, an unreachable webhook, a queue backlog and an inbox outage? Fourth, provider exit: can the business export the permitted data, create the replacement connection, test inbound and outbound flows and preserve the customer-service record? A clean exercise may still reveal a contract dependency; note it rather than treating it as failure of the test.

Before any migration, define the customer impact boundary. Which messages may be delayed? Who communicates with affected customers? What happens to messages in flight? How are assignment, consent, opt-out, attachments and audit records preserved? Who checks message status after cutover? What exact condition triggers rollback, and who has authority to execute it? Keep a record of the last known-good endpoint and configuration with secrets omitted or stored in an approved vault.

A rollback plan should be technically plausible. If the previous endpoint has been removed, its secrets revoked and its inbox shut down, saying “we can roll back” is inaccurate. Preserve the previous route for a defined period only if security and contractual policy allow it. Set a time limit, owner and decommission criteria, then test the process using non-customer messages. If the previous route cannot remain available, use a forward recovery plan and communicate that fact to stakeholders.

Failure modes that make a cheap route expensive

Assuming the phone number equals the customer record. The number may identify a messaging endpoint, but the thread history, notes and assignments can live in an inbox product. Test export and restoration independently. Do not assume all message data is attached to the number.

Comparing only message rates. Meta’s rates vary by category and market, while provider software and support can have separate charges. Compare the same scenario, delivery assumptions, categories and support scope. Re-check rate cards at the time of approval; old price screenshots age quickly.

Treating an account-sharing announcement as proof of migration. The June 2026 Meta session description is evidence of the described model, not a guarantee for every portfolio, provider, country or feature. Verify permissions and behavior for your actual account, and get the provider’s written explanation of what is shared and billed separately.

Selecting direct access without an operator. Direct access may reduce one software dependency while increasing internal duties. A Cloud API endpoint without alerting, retries, credential ownership, a staffed inbox and a named incident lead is not an operating model. Budget the people and tooling before calling the API fee a saving.

Choosing a partner without an exit clause. A good service can still become a dependency if exports, transition assistance, data deletion or termination timing are unspecified. Put operational transition details in the contract and verify that the written promise matches a test.

Trusting a demo that only shows the happy path. A demo that sends one message proves little about rejected templates, event duplication, slow delivery, export, role revocation or outage recovery. Use the same synthetic test sequence for every finalist and record outcomes in the register.

Storing secrets in the handover document. A continuity register should identify the vault entry or owner, never contain raw tokens, passwords or private keys. Restrict the register to people who need to know account structure; keep customer content and credentials in appropriately controlled systems.

Treating a U.S. security guide as Swiss legal advice. The FTC reference is a useful operational inventory sequence, but jurisdictional obligations depend on the parties, data, processing and transfer. Route legal questions to qualified counsel; do not copy a U.S. checklist into a Swiss contract as if it answered the law.