Choose direct WhatsApp Cloud API integration when your team wants control of the application workflow and can maintain it. Choose a Business Solution Provider, or BSP, when its inbox, operational tools, support, or onboarding remove work you would otherwise need to build. A provider can use Meta's Cloud API underneath, so these are often different operating arrangements on the same messaging platform.
The decision should name who handles customers, failures, billing, and account access after launch.
Separate messaging transport from the product
Cloud API sends messages and delivers webhook events. A customer support product also needs assignment, search, access controls, conversation history, reporting, and a way for a human to intervene.
A BSP may supply some of those features, depending on the product and contract. Another may primarily provide an API and billing relationship. Ask for a demonstration of the exact workflow rather than assuming every provider includes a shared inbox.
For an illustrative sales operation, incoming enquiries must become CRM activities, route to an available salesperson, and stop automated follow-ups when that person replies. Compare how each option implements that full sequence, including failed CRM writes and staff absence.
The CRM integration guide describes the application responsibilities behind that sequence.
Compare responsibility explicitly
| Responsibility | Direct integration | BSP arrangement |
|---|---|---|
| Inbox and agent tools | Build or connect a separate product | Verify included features and restrictions |
| API behavior and failures | Your engineers investigate and maintain the integration | Provider handles its layer; define escalation to Meta |
| Business workflow | Your application owns the rules | Depends on automation and integration capabilities |
| Billing | Manage your applicable Meta billing arrangement | Inspect Meta pass-through fees and provider charges |
| Templates and account access | Your team manages the required assets | Verify owner, permissions, export, and exit process |
| Data retention | Define storage and deletion in your application | Confirm provider storage, export, deletion, and subprocessors |
These are contracting questions, not guaranteed features of either arrangement. The API does not decide who will answer an unassigned customer enquiry.
Model total cost using the same workload
Last verified: October 2026. Meta's current developer documentation uses delivered-message billing and includes service-message charging after the applicable free allowance. Do not reuse an older conversation-based calculator or assume replies are universally free. Recipient market, category, currency, and account-specific eligibility matter; rates and policy can change.
For a comparison, give both options the same forecast of delivered message categories, recipient markets, agents, automations, and integration traffic. Keep Meta charges separate from provider subscription, seats, markup, implementation, and your own engineering work.
No provider price is quoted here because a current named contract was not verified. Ask whether incoming events, outgoing attempts, delivered messages, automation runs, or API access attract additional charges. Confirm how failed delivery and refunds appear on the invoice.
Direct integration can remove a provider fee while increasing maintenance work. A provider can reduce application work while introducing constraints or migration costs. Compare the monthly operating arrangement, not simply one message rate. Our pricing and messaging windows guide explains the current distinction between permission to send and a message's charge.
Verify account ownership before onboarding
Keep an inventory of the business portfolio, phone number, WhatsApp account, Messaging account, app, administrators, and payment relationship. Have the business confirm what it owns and which assets a provider can access.
Meta's account model has changed. Its current documentation separates the phone-number identity from templates and billing, allowing distinct Messaging accounts around the same number. Existing screens and identifiers can reflect a staged transition, so inspect the actual account rather than following a screenshot from an older guide.
Do not promise that removing a provider will transfer every asset. Template availability, billing setup, webhook subscriptions, and routing require separate checks. A number visible in a provider dashboard is not sufficient evidence of the customer's administrative control.
Ask the provider to explain its exit process before signing. Useful evidence includes the business's administrator access, a sample export, the deletion procedure, and a written list of charges that survive cancellation.
Support quality is observable
Test support with an actual integration question during evaluation. Ask how to investigate an accepted message without a delivery event, a rejected template, a revoked token, or a failed CRM callback.
A useful answer identifies the evidence required, the responsible support team, and escalation boundaries. A promise of priority support is hard to assess without response coverage, working hours, and access to meaningful logs.
Define your own first response too. Someone in the business should be able to pause campaigns or automation without waiting for a developer. If the provider's UI is the only place to do that, include administrator availability in the operating plan.
Direct integration requires more than a send request
Plan for authenticated webhooks, durable event storage, deduplication, queued processing, delivery status tracking, and limited retries. Store an outbound business intention before sending so a crash does not silently lose the message.
A timeout creates ambiguity: Meta may have accepted the request even though your server did not receive the response. An outbox helps coordinate your own work but does not automatically prevent a duplicate at an external API. Define a reconciliation and manual-review path before blindly retrying customer-facing messages.
Also plan token rotation, webhook schema changes, restricted logging, and a release process. These responsibilities remain somewhere in the system even when a provider implements part of them.
The Cloud API integration guide provides a concrete implementation sequence.
Choose using a small operational pilot
Run one inbound enquiry and one legitimate outbound notification through each candidate arrangement. Include an opt-out, an absent salesperson, a duplicate event, and a temporary CRM outage. Have the people who will operate the inbox participate.
Choose direct integration when the custom workflow is central to the product and the team can own its behavior. Choose a BSP when the demonstrated operational product saves enough work and its ownership, data, and exit terms are acceptable. A mixed arrangement can be useful, but it requires deliberate conversation routing and clear authority over automated replies.
Apex's WhatsApp integration team builds direct Cloud API workflows and integrates BSP products when the business prefers that operating model.