When a client says "we want WhatsApp integration," there are two questions they're actually asking at once — and conflating them will cost you time.
Question 1: How does the WhatsApp Business API technically work?
Question 2: Which Business Solution Provider (BSP) should we route through?
This guide covers both. It's written for developers who need to set up a WhatsApp integration and want to make a smart BSP choice upfront — not six weeks in when you discover the one you picked doesn't support the features you need.
How the WhatsApp Business API actually works (architecture overview)
Meta doesn't offer direct API access to individual businesses. The full picture is:
Your Application
↓
BSP (Business Solution Provider)
↓
Meta's WhatsApp Business Platform (Cloud API)
↓
End user's WhatsApp
Since October 2025, Meta deprecated the On-Premises API entirely. Cloud API is now the only supported architecture. This means your BSP is always routing through Meta's Cloud API — what varies is the layer of tooling, reliability, pricing, and features the BSP adds on top.
What Meta's Cloud API gives you directly:
Send/receive messages via webhook
Template message management
Media support (images, documents, video, audio)
Interactive messages (buttons, list pickers)
Read receipts and delivery callbacks
What BSPs add:
Dashboard-based management (no raw API calls)
Chatbot/flow builders
Multi-agent inbox
Broadcast campaign management
CRM and ecommerce integrations
Analytics
WhatsApp Commerce (catalog + orders)
Webhook reliability and retry logic
If you're building a custom integration, you can go Meta Cloud API direct. But for most business applications — especially if non-technical users need to manage campaigns or chatbots — you're going through a BSP.
BSP vs Direct Cloud API: when to use which
Key technical criteria when evaluating BSPs
Here's what actually matters under the hood.
**Webhook reliability and retry behavior
**When Meta delivers a message to your BSP, how does the BSP handle delivery to your endpoint? Does it retry on failure? What's the SLA? For production systems handling high message volume, this is critical. Ask BSPs directly about their webhook retry logic and uptime SLA.
**Template approval pipeline
**All outbound messages outside a 24-hour service window require pre-approved Message Templates. Different BSPs have different UIs and approval times for managing templates. Some offer bulk template submission; others do it one by one. For clients who run campaigns, this adds up.
**Embedded Signup support
**Meta's Embedded Signup lets users connect their WhatsApp Business Account without leaving your UI. If you're building a SaaS product that needs to connect multiple client WhatsApp numbers, BSP support for Embedded Signup (and System User Token management) is essential.
**Multi-WABA support
**If you're building for an agency or platform that manages multiple clients, you need a BSP that supports multiple WhatsApp Business Accounts (WABAs) under one umbrella. Not all BSPs handle this cleanly.
**Webhook schema documentation
**Before committing, read the BSP's webhook documentation. Inconsistent or poorly documented webhook schemas create integration headaches. Good BSPs publish detailed schemas with examples for every event type.
**Rate limits and throughput
**Meta sets message throughput tiers (1K, 10K, 100K messages per day) based on business verification and messaging quality. Your BSP should be transparent about how these tiers are managed and how throughput scales.
The BSP landscape in 2026: a developer's view
There are three tiers of BSPs worth knowing:
**Developer-first platforms (Twilio, 360dialog)
**Twilio offers a WhatsApp API through its Programmable Messaging platform — well-documented, global infrastructure, strong SDKs. High flexibility but no no-code dashboard. 360dialog offers lightweight API-direct access with fast Embedded Signup. Both are good if you want full control and have developer resources.
**Marketing-focused platforms (AiSensy, Wati, Interakt)
**These prioritize the campaign management and broadcast use case. Strong UIs for marketers. Chatbot builders vary in depth. Commerce and appointment features are usually partial. Interakt has solid e-commerce workflow support; AiSensy is strong on broadcast automation.
**Full-stack growth platforms (Happilee, Respond.io)
**These aim to cover the entire customer journey — from Click-to-WhatsApp ad capture, through chatbot qualification, to WhatsApp Commerce checkout and appointment booking. For client projects where WhatsApp needs to be a revenue channel (not just a support channel), these are worth evaluating. Happilee in particular positions itself as an all-in-one WhatsApp growth engine combining chatbot automation, commerce, scheduling, and ad funnels — a useful comparison benchmark when scoping features.
For a full side-by-side of options, this WhatsApp API provider comparison covers the key platforms in detail.
A practical integration checklist
Before your first API call:
Infrastructure
☐ Business Manager verified
☐ App in Live mode (not Development)
☐ System User Token provisioned (not personal user token — it expires)
☐ Phone number registered to WABA
☐ Webhook endpoint HTTPS, publicly accessible
☐ Webhook verification token set
Messaging
☐ At least one approved Message Template
☐ Test template send confirmed
☐ Inbound webhook receiving correctly
☐ Media upload tested (if using images/docs)
Operations
☐ BSP support contact documented
☐ Fallback plan if BSP has outage (especially for campaign days)
☐ Template approval timeline understood (typically 24–48hrs)
☐ Conversation pricing model understood (utility vs marketing vs service)
Common integration mistakes
Using a personal user access token instead of a System User Token
Personal tokens are tied to a user account and expire. System User Tokens persist. Always use System User Tokens in production.
Not handling 24-hour window correctly
You can only send free-form messages within 24 hours of the last customer message. Outside that window, only approved templates work. Not handling this logic leads to message failures that are hard to debug.
Ignoring message quality ratings
Meta tracks user feedback on your messages. High block or report rates can drop your daily messaging tier. Monitor your quality rating dashboard and don't blast contacts who didn't opt in.
Webhook endpoint without idempotency
Meta can deliver the same webhook event more than once. If your handler isn't idempotent (i.e., processing a duplicate message ID causes duplicate actions), you'll hit bugs in production.
Final thoughts
The WhatsApp API is genuinely powerful — but the BSP decision deserves real evaluation time. The technical layer matters less than most developers expect; what matters more is the feature layer above it (chatbots, commerce, analytics) and how well that fits your client's use case.
Spend 30 minutes on each shortlisted BSP's documentation before you start building. The gaps become obvious quickly.
Drop questions in the comments — happy to help with specific integration scenarios.
Top comments (0)