Three different products share the name, and the rules that trip teams up aren't in the API docs. Here's the version we wish we'd read first.
Almost every WhatsApp project starts with the same confusion, because three separate things share one name. The WhatsApp Business app is the free mobile app a shop owner installs: one phone, one person answering, no automation. The WhatsApp Business Platform (what everyone calls "the API") has no app and no inbox at all; it's a messaging endpoint your software talks to, and whatever interface your team uses is something you or a vendor builds on top. Meta has since retired the old self-hosted On-Premises API, so for anything new there is really only one path: the Cloud API, hosted by Meta. We built a booking chatbot on it for a home-services marketplace, so what follows is what actually bit us, not a summary of the documentation.
WhatsApp is not email, and the single biggest adjustment is that you cannot say whatever you want whenever you want. When a customer messages you, a 24-hour customer service window opens, and inside it you can reply freely: plain text, images, PDFs, buttons, whatever your flow needs. When that window closes, free-form messages stop being delivered, and the only way to reach that person again is a message template you submitted to Meta in advance and got approved.
Templates come in three categories (Marketing, Utility, and Authentication), and the category you pick is a claim about intent that Meta reviews. An order-shipped notification is Utility. A login code is Authentication. A discount announcement is Marketing, no matter how you word it. Approval is usually a matter of minutes, but the two rejections you'll actually hit are a promotional message filed as Utility, and variable placeholders submitted without believable example values. Design your flows around this: every message your system might need to send outside a live conversation has to exist as an approved template before you launch, not after.
The plumbing itself is unremarkable. You point Meta at a public HTTPS webhook with a verify token, and you receive inbound messages and delivery status callbacks (sent, delivered, read, failed) on the same endpoint. Interactive message types are worth knowing before you design anything: up to three reply buttons, list messages up to ten rows, URL call-to-action buttons, and WhatsApp Flows if you need a real form inside the chat rather than a ten-question interrogation.
Pricing is per template message delivered, set by the template's category and the recipient's country. Free-form replies inside the customer service window aren't billed, which flips the economics in a useful direction: a support or booking use case, where customers start the conversation and you answer, costs strikingly little. Outbound notification campaigns are where the bill lives. Click-to-WhatsApp ads and Page call-to-action entry points open a longer free window, which is why so many businesses route acquisition through them. Rates differ enormously between countries and Meta adjusts them, so price your specific markets against the current rate card rather than a blog post: India sits at the cheaper end, which is precisely why volume assumptions built there don't transfer.
The constraint teams don't plan for isn't price, it's quality rating. Every sending number carries a rating driven by how recipients react (blocks and reports drag it down), and that rating governs your messaging tier: how many unique customers you may message in a rolling 24 hours. New numbers start capped, and the cap lifts as you send consistently at good quality. It can also fall. A single badly targeted marketing blast to a list that never meaningfully opted in can throttle the number your genuine order notifications depend on, and warming a fresh number back up takes weeks. Opt-in isn't a compliance checkbox on this platform; it's the thing protecting your delivery capacity.
You have engineers who'll own the webhook, the template library, and the retry logic anyway.
Volume is high enough that a per-message reseller markup becomes a real line item.
The conversation has to reach deep into your own systems (inventory, bookings, CRM) where a generic inbox would just be a hop in the middle.
Humans need to answer some of these chats, and you'd rather buy a team inbox with agent handover than build one.
You're piloting, and want to be live in days without standing up infrastructure to find out whether customers even use it.
Local billing, local support, and someone else chasing template approvals are worth more to you than the markup costs.
Only by migrating it. A phone number can live in exactly one place: the WhatsApp Business app or the Business Platform, never both. Migrating brings the number and display name across, but the app stops working on that number and your team loses the phone-based inbox unless you replace it with an agent console. Teams that want to keep answering by phone usually onboard a second number instead.
Usually minutes, occasionally up to 24 hours. Most rejections come down to two things: a promotional message submitted under the Utility category rather than Marketing, or variable placeholders submitted without realistic example values. Fix the category or the samples and resubmit: approval is per template, so a rejection doesn't affect templates already live.
Meta charges per template message delivered, priced by template category and the recipient's country. Free-form replies you send inside the 24-hour customer service window aren't charged, so a support-heavy use case can cost very little. India is one of the cheaper markets, but rates move: check Meta's current rate card for the countries you actually message. If you go through a BSP, add their per-message markup and any platform fee on top.
Only to people who have opted in, and only using an approved Marketing-category template. Opt-in is a hard requirement, not a formality: if recipients block or report your messages, your number's quality rating drops and Meta caps how many unique customers you can message per day. A list bought or scraped from somewhere else is the fastest way to get a number restricted.
You can go direct. The Cloud API is open to any business that completes Meta Business verification, so a BSP is no longer a gatekeeper. What a BSP sells now is convenience (a shared team inbox, template management, agent handover, and local billing and support), which is worth real money if you don't want to build and run that yourself.
A demo that impresses in a meeting and a bot that survives real customers are two different bars.
Read the guideNot every chatbot needs a language model behind it. The decision affects cost, predictability, and maintenance.
Read the guide