Direct WhatsApp Cloud API vs BSP: what founders should know.

Every Indian B2B founder running customer messaging on WhatsApp eventually arrives at the same question. They started with a business phone number on the WhatsApp Business app. Volume grew. They added a Business Solution Provider, usually AiSensy or Wati or Gallabox or Interakt, because the sales page promised broadcast capability and template management. The BSP works. The monthly bill keeps growing. Somewhere around the eighteenth month, the founder asks the next question: do we need this BSP, or can we go direct to WhatsApp?

The answer is technical, not ideological. Going direct to the WhatsApp Business Cloud API is the right architectural choice for some businesses and the wrong one for others. The honest analysis depends on a handful of specific factors that BSP comparison pages do not address, because the comparison pages are written by BSPs.

This essay is the analysis. It is written from inside the work of integrating WhatsApp Cloud API directly into operational systems for mid-market Indian businesses. It will not tell you that direct is always better. It will tell you what direct actually involves, what the BSP is actually doing for the fee they charge, and how to decide which one fits your business.

What a BSP actually is, and what they charge for

A Business Solution Provider is, in technical terms, a layer between your application and the WhatsApp Business Cloud API. The BSP holds a WABA (WhatsApp Business Account) on your behalf, manages the templated message approvals with Meta, handles the API authentication, exposes a dashboard for non-technical users, and bills you for the service.

The fee a BSP charges has three components, often bundled into a single monthly invoice that obscures the structure.

The first component is the pass-through Meta conversation cost. Meta charges WABAs per conversation, in three categories: marketing, utility, and service. The rates are public, set in INR, and update periodically. The BSP pays this to Meta and passes it on to you, usually at a markup of fifteen to forty percent. This is the cost you cannot avoid, regardless of how you connect, because Meta charges it directly to the WABA.

The second component is the BSP's own platform fee. A flat monthly subscription, sometimes with usage tiers. This pays for the BSP's infrastructure, their support team, their dashboard, their broadcast tools, and the work of maintaining the integration with Meta's evolving API. The fee varies widely. Smaller BSPs charge a few thousand rupees a month. Enterprise-grade providers charge in the tens of thousands or more, with per-user pricing layered on top.

The third component is the value-added services. Contact management, broadcast composition tools, chatbot builders, analytics dashboards, integrations with HubSpot or Zoho. These are the features the sales page emphasises, and the part of the BSP most founders use least, because their operational system already holds the customer data.

The total monthly cost, for a business sending a few thousand messages a month, typically falls in the ten to forty thousand rupee range. For businesses sending tens of thousands, it rises into the lakhs.

What you give up when you go through a BSP

The cost is the visible trade-off. The less visible trade-offs are architectural, and they matter more over a long-term horizon.

The conversation data lives partly inside the BSP's platform. Some BSPs offer full export. Some offer partial export. The structured history of who messaged what, when, attached to which customer record, is shaped by the BSP's data model rather than yours. If you ever change BSPs, the migration is non-trivial.

The template approval workflow is mediated by the BSP. A template that fails Meta's review process surfaces to you through the BSP's dashboard, sometimes with limited context. The BSP's support team becomes the interpreter between your business and Meta's policy. When templates need to change quickly, the BSP's response time becomes your response time.

The integration with your operational system runs through the BSP's API or webhook layer. The BSP's reliability is your reliability for WhatsApp delivery. When the BSP has an outage, your messaging is down. When the BSP changes its API, your integration needs to update to match. The dependency is real and easy to underestimate.

The phone number sometimes registers in the BSP's name or shared infrastructure, depending on the provider. Moving the number to a different BSP, or to your own direct integration, requires a migration process. The number is yours legally, but the technical custody belongs to the BSP for the contract duration.

These are not deal-breakers. They are real considerations that BSP sales conversations rarely surface.

What direct WhatsApp Business Cloud API requires

Going direct to the WhatsApp Business Cloud API means your application talks to Meta's API directly, without a BSP between you. The architectural picture is straightforward. Your application holds the access token. Your application authenticates to the Meta Graph API endpoint for WhatsApp Business. Your application sends messages, receives webhook callbacks for inbound messages and delivery receipts, and stores the conversation history in your own database.

The setup involves several steps. You need a Meta Business Manager account, a WhatsApp Business Account inside it, a verified business phone number, and a Meta-approved application with the WhatsApp Business permissions. Templates need to be submitted through the Business Manager interface and approved by Meta. The webhook endpoint on your side needs to be verified, secured, and reliable enough to receive every inbound message Meta dispatches.

The technical effort is real but bounded. For a business already running a custom operational system, the integration sits at the application layer alongside other API integrations. The operational complexity is in template management, rate limit handling, and delivery receipt processing.

The capability you gain is structural. The conversation history lives in your database. The customer record carries the full WhatsApp conversation as one of its data dimensions. Templates are managed inside your own application. Outages on Meta's side are the only thing that can interrupt your messaging, because there is no intermediate layer that can fail independently. The cost is the Meta conversation fee, paid directly, with no markup.

This is the architecture that runs at AKSD, where WhatsApp notifications for proforma invoices, order confirmations, and dispatch updates all dispatch from the firm's own ERP through direct Cloud API integration. It is also what runs at Lucky Traders, where the customer portal's structured order flow replaced informal WhatsApp order intake, and where the system-generated confirmations dispatch through direct integration.

In both cases, the firm pays Meta directly for the conversations that take place. Nothing else. The marginal cost per additional order is the Meta conversation rate, which is small.

Cost comparison: BSP markup vs Cloud API per-conversation

The cost analysis depends on volume. Below a certain threshold, the BSP's monthly fee is small relative to your business, and the engineering time to build direct integration is not worth it. Above that threshold, the BSP's markup compounds and the direct integration pays for itself quickly.

For a business sending one thousand utility conversations a month through a BSP at a thirty percent markup, the monthly Meta cost is a few thousand rupees and the BSP markup is around a thousand rupees, plus the BSP's flat platform fee of ten to twenty thousand. The total is in the range of fifteen to twenty-five thousand a month.

For a business sending ten thousand conversations a month, the same structure produces a Meta cost of a few tens of thousands, a BSP markup of around ten thousand on the per-conversation fee, plus a larger platform fee that scales with usage or contact list size. Total monthly cost climbs into the low lakhs.

A direct integration eliminates the markup and the platform fee. The firm pays Meta for the conversations and pays nothing else. The engineering effort is a one-time investment, with ongoing maintenance that is usually a small fraction of the BSP's monthly fee.

The payback period depends on the volume. For most businesses sending more than a few thousand conversations a month, the direct integration pays for itself inside a year. For businesses sending tens of thousands, the payback is months.

When the BSP is the right answer (yes, sometimes)

The direct integration is not always correct. Three scenarios make the BSP the right choice, and a fitted answer should acknowledge them.

The first is small volume with minimal engineering capacity. A business sending a few hundred conversations a month, with no operational system in place to integrate with, gains little from direct integration and gains a lot from the BSP's out-of-the-box broadcast capability. The BSP's monthly fee is small relative to the engineering effort that direct integration would require, even with the markup.

The second is when the BSP's value-added features are central to the business. Some BSPs offer chatbot builders, conversational AI integrations, or advanced segmentation tools that take engineering effort to replicate. If those features are critical to how the business operates, paying for them through the BSP is rational.

The third is when the business explicitly wants the BSP to own the operational risk of WhatsApp messaging. Template approvals, policy compliance, account suspension recovery, the operational overhead of maintaining a WABA in good standing with Meta. A BSP absorbs this work. For a business that does not want to handle it internally, the BSP is paying for itself in operational simplicity even when the direct integration would be cheaper.

The direct integration is the right architectural choice when the business has, or is willing to invest in, a custom operational system that benefits from WhatsApp being a first-class data dimension. The BSP is the right choice when the business primarily needs broadcast capability layered on an external CRM, with no plans to build deeper integration.

The deciding question, in our experience, is whether the WhatsApp conversation history is a strategic asset for the firm or a transactional channel. If it is an asset, integrate directly. If it is a channel, use a BSP.

How we run direct integrations

The pattern that has worked, across the firms running direct integrations on this site, is structurally consistent.

The WABA is registered to the firm directly, in the firm's Business Manager account. The phone number is the firm's own. The access tokens are held in the firm's application configuration. Templates are managed from the firm's own admin interface, with submission to Meta running through the Business Manager API.

The application code handles outbound message dispatch, inbound webhook reception, delivery receipt processing, and conversation storage in the same database that holds the rest of the operational record. The customer record carries the WhatsApp thread as one of its dimensions, alongside the order history, the proforma history, and the email history.

The operational dashboard inside the application surfaces the WhatsApp activity in context. A team member looking at a customer record sees every conversation the firm has ever had with that customer, across every channel. There is no separate BSP dashboard to switch into.

The cost structure is the Meta conversation fee, paid directly. The infrastructure cost is whatever the firm's existing application hosting costs. The integration cost is the engineering investment to build it, which amortises over the years the firm runs on the system.

This is the architecture we default to for firms operating at sufficient volume to justify it. The decision is not ideological. It follows from looking honestly at what the BSP layer is doing, what it costs, and what the firm gains by removing it. For smaller operations with different priorities, the BSP remains the appropriate choice.

The longer treatment of how this flows into a fitted operational stack is at performance marketing.