WhatsApp is the channel Indian customers actually read, which is why every product roadmap eventually has “WhatsApp integration” on it. The gap between that line and a working integration is wider than it looks, and almost all of the difficulty is in rules rather than in code.
Here is what the platform is, in the terms that matter when you are deciding whether to build on it.
Three different products with similar names
WhatsApp Messenger is the consumer app. Automating it is against the terms and the account gets banned, usually at the worst moment.
WhatsApp Business App is the free app for small businesses: one number, one phone, quick replies, a catalogue. Genuinely useful and not programmable in any meaningful way.
WhatsApp Business Platform, the API, is the one this article is about. There is no app: messages arrive at your system and are sent from it, which means everything a human would have done has to be built. It also means several people can work one number, which is usually the real reason a business moves to it.
The session window is the rule everything else follows from
You cannot message whoever you like whenever you like. The platform divides messages in two.
Inside a 24-hour window, opened when the customer messages you, you can reply freely with any content. The window closes 24 hours after their last message.
Outside it, you can only send a template: a message approved in advance, with variables filled in. No free text.
Every product decision follows from this. A support conversation is comfortable, because the customer starts it. A notification, a reminder, an abandoned-cart nudge or an offer all happen outside the window and therefore need templates, approval, and opt-in.
Templates, and why they get rejected
A template is submitted, reviewed and either approved or rejected, usually quickly. Rejections cluster around a few causes and they are worth knowing before you write fifty of them:
- Variables at the very start or end, or two variables adjacent with nothing between them, which makes the message impossible to review.
- Content that is promotional in a category declared as utility. Categorisation is not a formality; it affects both approval and price.
- Vague placeholders. A template that is mostly variables reads as a way to send anything at all, and it is treated that way.
- Anything the policy prohibits outright, which includes several regulated categories and is worth reading rather than guessing.
Practical consequence for a build: templates are content that needs approval lead time, so they belong in the project plan next to design, not in the week before launch. Editing an approved template resubmits it. Version them, and never let the code assume a template exists without checking.
How the money works
Billing is per conversation rather than per message, in categories: marketing, utility, authentication and service. A conversation is a 24-hour block from the first message in it, and every message inside that block is included. Rates differ by category and by country, and Meta revises them.
Two consequences that catch teams out. First, a chatty exchange costs the same as a single message, so there is no reason to be terse. Second, marketing conversations are the expensive category and the easiest to send by accident at volume; a loop that messages ten thousand customers is a real bill, not a rounding error. Put a rate limit and a spend ceiling in the code, not in the runbook.
Do not price a project from any figure in an article, this one included. Take the current rate card for India for the categories you will actually use.
Opt-in is a requirement, not a courtesy
You need consent before sending a template message, you must record where and when it was given, and the user has to know what they are agreeing to receive. Beyond the platform’s own rules, this is personal data under the DPDP Act: the number, the message history and the consent record all need a retention policy and a deletion path.
Build the consent record as a first-class thing, with a timestamp, a source and a copy of the wording shown. Reconstructing it later, when someone complains or the account is reviewed, is not possible.
What it will not do
- It is not a broadcast channel. Sending the same offer to a large list is exactly the behaviour that gets a number’s quality rating downgraded, and a downgraded number sends fewer messages per day.
- It is not a support inbox on its own. There is no interface. Either you buy one from a provider or you build the agent view, and building it is a real project.
- Rich formatting is limited. Buttons and lists exist within defined structures. It is not a web page.
- Delivery is not guaranteed and read receipts can be off. Any flow that depends on knowing a message was read needs a fallback.
- It does not replace email for anything that must be retrievable later. Invoices and contracts belong somewhere a customer can search.
Where it genuinely earns its place
Transactional messages people want and currently miss: order confirmed, out for delivery, appointment tomorrow, payment received, document ready. These are utility conversations, they are cheap, they are opened, and they remove support calls. That is a smaller ambition than most WhatsApp projects start with and it is the one that reliably pays.
Getting the number and the account in place
Before any code runs there is an onboarding sequence, and it takes longer than teams expect. A Meta business account, verification of the business itself, a phone number that is not already registered on WhatsApp, and a display name that has to be approved and is awkward to change afterwards.
Two details worth knowing early. The number cannot be in use on the consumer app, so a business that has been using WhatsApp on a staff phone has to migrate that number deliberately or choose a new one, and choosing a new one means telling every existing customer. And business verification asks for documentation of the legal entity, which is not something to discover in launch week.
Once live, the number carries a quality rating and a messaging limit that rises with good behaviour and falls with blocks and reports. Sending too much, too soon, to people who did not expect it, is how a new number gets restricted in its first fortnight. Ramp up rather than launching a campaign on day one.
Direct, or through a provider
Most businesses reach the platform through a solution provider rather than building against it directly, and the trade is worth understanding.
Through a provider you get an agent inbox, template management, often a flow builder, and support with onboarding. You pay a platform fee on top of Meta’s conversation charge, and your message history lives with them. The lock-in is real but not fatal: the number is yours and can be migrated.
Direct costs less per message, gives you complete control of the data, and means you build everything a provider would have given you, including the agent interface. It makes sense when messaging is core to the product rather than a channel bolted onto it.
A reasonable default is to start with a provider, keep your own record of every message in your own database from day one, and revisit once volume makes the platform fee comparable to a developer’s time.
The engineering side of an integration, from webhook reliability to what to store, is a separate subject and we build it as part of our conversational and automation work. If you are trying to decide whether the API is worth it for your volume, tell us what you want to send and to how many people and we will work through the arithmetic with you.