Three Ways to Receive WhatsApp Inbound Messages: Cloud API, BSP, and Unofficial Interface Compared — UnifyPort
The question of how to receive inbound WhatsApp messages sounds like a solved problem, but there’s a meaningful gap between the three available paths. Choosing the wrong one adds weeks to your timeline or dollars to your unit economics.
One thing worth knowing before comparing: the WhatsApp On-Premises API reached end-of-life on October 23, 2025. If you’re reading older documentation that references running WhatsApp docker containers on your own infrastructure, that path is closed. Everything runs on Cloud API now, or on alternatives to the official API entirely.
Path 1: Meta Cloud API (direct)
The official route. You register a phone number in Meta’s Business Platform, connect a webhook, and receive inbound events directly from Meta’s servers — no middleware.
What you need: A Facebook Business Manager account, a Meta Developer account, a phone number that has never been registered on WhatsApp, and business documents for verification (tax ID, incorporation certificate, or utility bill).
Setup time: The technical work — creating an app, registering a number, configuring a webhook — takes under an hour. The bottleneck is Business Verification. Submitting documentation and waiting for Meta’s approval typically takes 2–5 business days, with some cases running to two weeks.
Before verification completes: Your account is limited to 250 business-initiated conversations per rolling 24-hour period. User-initiated conversations — where the user messages you first — are not subject to this limit, so if your use case is primarily inbound, you can start receiving before verification clears, just not send proactively at volume.
After verification: Messaging limits increase to Tier 1 (1,000 business-initiated conversations per 24 hours), with higher tiers available as your quality rating improves.
Cost: API access is free. Since July 1, 2025, WhatsApp charges per delivered template message, priced by category (marketing, utility, authentication, service) and the recipient’s country. 1,000 free service conversations per month. You own and pay for your webhook endpoint infrastructure.
Path 2: Business Solution Provider (BSP)
BSPs are Meta-certified companies that resell WhatsApp Business API access. Instead of dealing with Meta directly, you onboard through the BSP’s platform — they handle API connectivity and webhook delivery, and usually provide a management UI on top.
Well-known BSPs include Twilio, WATI, 360dialog, SleekFlow, 1msg, and Vonage.
Setup time: Generally faster than Cloud API direct — BSPs streamline onboarding with guided wizards. Some claim hours for basic use cases, though the underlying Meta verification requirements still apply for higher messaging tiers.
Cost:
- Meta’s per-message charges (same base rates as direct access)
- BSP markup: typically $0.003–$0.010 per message, or 10–30% on top
- Monthly platform fees: $29–$500+/month depending on tier
- Per-number fees: some BSPs charge additionally per connected number (e.g., $15/month/number)
At low volumes, the monthly platform fees dominate. At high volumes, the per-message markup becomes the significant cost. Either way, you’re paying more than direct Cloud API access.
What you get: Managed infrastructure, a UI for inbox and template management, compliance guidance, and a support layer that knows WhatsApp’s policies.
Path 3: Unofficial inbound interface
The third path doesn’t go through Meta’s API stack. An unofficial inbound interface connects to WhatsApp through WhatsApp Web — the same mechanism a browser uses — to receive inbound messages as structured webhook events.
This is the path UnifyPort takes for inbound. An ordinary WhatsApp account — any number, including one your customers already have in their contacts — connects once. Every inbound message is normalized into a standard message.received event and delivered to your webhook with an HMAC-SHA256 signature.
What you need: An existing WhatsApp account. A webhook endpoint.
Setup time: Under a day. No documents, no approval queue, no Business Manager required. For a real-world example of what this timeline looks like in practice, see how a Southeast Asian team went live in three days.
Cost: A service subscription rather than per-message billing. No Meta charges on the inbound side.
What you get: Fast start, existing-number continuity, and inbound events structurally identical to events from Telegram, LINE, TikTok, Zalo, and X — one schema, every channel.
What you take on: This approach operates outside WhatsApp’s Terms of Service. WhatsApp actively detects unofficial API usage through behavioral analysis and pattern matching. Accounts used this way carry suspension risk if usage patterns trigger detection. This is the primary tradeoff, and it’s not theoretical.
Side-by-side
| Cloud API (direct) | BSP | Unofficial inbound | |
|---|---|---|---|
| Time to first webhook | Hours + 2–14 days (verification) | Hours to days | Under a day |
| Verification required | Yes | Varies by provider | No |
| Existing number usable | No (unused number only) | No | Yes |
| Base API cost | Free (pay per message) | Free + 10–30% markup | Subscription |
| Monthly platform fee | None | $29–$500+ | Subscription |
| Data routing | Meta → you directly | Through BSP | Through service |
| ToS compliant | Yes | Yes | No |
| Multi-channel normalization | No | No | Yes (6 platforms) |
Which fits which situation
Cloud API direct when: you’re building at scale, compliance status matters, you have runway to wait for verification, and you want the lowest unit cost long-term.
BSP when: your team is non-technical and the inbox UI matters, you want template management without building it, and the additional cost is worth the time saved.
Unofficial inbound when: you need to receive messages now, your existing number is already in customers’ contacts, the verification queue would stall your launch by weeks, and you’ve evaluated the ToS risk and accepted it. Also when you want one normalized event schema across every channel your business uses.
The three paths aren’t competing for the same customer. Most teams that switch eventually revisit this comparison. It’s worth understanding all three before you pick one. If you’re also weighing Telegram as an alternative to WhatsApp for inbound, the cost and setup comparison between the two is here.