WhatsApp operations: what the Cloud API allows

In El Salvador, business runs on WhatsApp. Appointments get confirmed there, orders get coordinated there, customers get answered there, almost always from a phone somebody has to keep watching. The same is true across most of Latin America, and it surprises buyers who are used to email being the default channel.

The question we always get is the same: "can that be automated?". The answer is yes, substantially, but not in the way most people imagine, and the rules that limit it are not technical. They are Meta's, and they exist so that businesses cannot do to people what they did with SMS.

This piece is about what the Cloud API genuinely allows, what constrains what you can send, and what you will not be able to do regardless of budget.

Three different things people call "WhatsApp"

The WhatsApp Business app. The one you install on a phone. Catalogue, labels, quick replies, away messages. It does not integrate with your system: what happens in there stays in there. For a lot of businesses it is enough, and they should not be sold anything else.

The Cloud API. Meta's programmatic route. Your system sends and receives messages on its own, with nobody touching a phone. It is what makes it possible for an appointment booked in your system to trigger a confirmation with no human involved. It is also what requires a build.

A BSP, or Business Solution Provider. An intermediary giving you an interface on top of the API, usually with a shared inbox, reporting and its own billing. It saves you the build, and in exchange your conversations pass through a third party and you are tied to their product.

Choosing between the three is the same decision that shows up in custom software or SaaS: the app is not building, the BSP is renting, the API is building. None of them is always the right answer.

Approved templates are the rule that shapes everything

This is the part that surprises everyone, so it is worth saying plainly: you cannot message a customer whatever you like, whenever you like.

To start a conversation you have to use a template, and templates are submitted to Meta for approval before you can send them. You define the text with variables, they review it, and only then can you send. Meta's own documentation is explicit that a template is the only type of message that can be sent to a user outside of a customer service window.

Three practical consequences follow, and none is obvious until you are inside:

A new template is not available the same day. If your operation needs a notice you had not anticipated, there is a wait before you can send it.

The wording is fixed. You can change the variables, not the sentence. Every genuinely different message is one more template to maintain.

And not everything gets approved. Promotional content plays by different rules than transactional content, and a rejected template has to be rewritten and resubmitted.

The service window, and why it works in your favour

When a customer messages you, a window opens during which you can reply freely, without a template, like a normal conversation. Outside that window you need an approved template again.

That sounds like a limitation and it is actually the good part of the design. It means the system rewards answering quickly whoever reached out to you, and makes it expensive to interrupt whoever did not. It is precisely the incentive that keeps the channel working at all.

For a real operation the consequence is architectural: the system has to know whether the window is open before deciding how to send a message. A system that does not track that will try to reply in free text when it no longer can, and that message simply does not arrive.

What automates, and what does not

Anything that is a consequence of something that happened in your system automates well. Confirmation when an appointment is booked. Reminder the day before. Rescheduling notice when somebody moves the time. Notification that an order has shipped. Recovery of a cancelled appointment. In the scheduling systems we have put into production, those four or five notices are most of the value, and they are also the easiest.

Inbound automates halfway. Messages people send you reach your system through webhooks, which means your server receives them and can act. A menu of options, a status lookup, a confirm-by-reply all work well. Open conversation works far worse than demos suggest, and the honest design escalates to a person the moment the customer steps off the expected path.

The relationship does not automate. If your customer is writing because they are upset, no flow is going to fix that, and trying makes it worse. The rule we apply is simple: automate what is information, escalate what is judgement.

Coexisting with the number you already use

The most common objection, and the most reasonable: "my team uses that number every day".

A number cannot be on the WhatsApp Business app and on the Cloud API at the same time. That leaves three paths, and it is worth choosing before building anything rather than after.

You can migrate the number to the API and give your team a connected inbox, so they keep answering but from a different tool. You can use a new number for the automated traffic and leave the existing one to people, which is simpler and costs you customers seeing two numbers. Or you can not migrate, if the volume does not justify it.

The question that settles it is how many of your outbound messages are notices nobody needs to write by hand. If that is most of them, migrating pays for itself. If your operation is mostly human conversation, it probably does not.

Costs, as a structure

We are not going to print rates, because they age badly and because the ones for your country and your case are published by Meta. What is worth understanding is the shape of the charge, which is not what people assume.

You do not pay per message, you pay per conversation. A billing window opens and within it the number of messages does not change the price. And conversations the customer starts are treated differently from the ones you start.

The design consequence is counterintuitive: grouping notices inside one window is cheaper than scattering them, and a flow that gets the customer to write first costs differently from one that interrupts them. If you are going to send volume, this gets modelled before you build, not after the first invoice.

When it is not worth it

If your notice volume is low, the WhatsApp Business app and one organised person will serve you better than any integration. The Cloud API has a build cost and an operating cost, and below a certain volume neither is recovered.

It is also not worth it if the process you would automate is not settled. Automating notices on a flow that changes monthly means rewriting templates monthly, approval wait included every time.

And if what you want is a bot that handles your customers so you do not have to, the honest answer is that it does not work and people can tell. That is one of the questions worth asking any vendor who promises it.

If you want to know which of the three paths applies to your operation, that gets settled in half an hour.

WhatsApp's policies and pricing model belong to Meta and change. Templates, their approval, the customer service window and webhook delivery were verified against Meta's official documentation as of 16 August 2026. Confirm current rates and policies before committing a budget.

If you are weighing moving WhatsApp off a phone and into your system, we can go through your case with you. The discovery call runs thirty minutes, it is free and carries no obligation, and it is useful for ruling out the wrong path even if we never work together. You can book it here. What we build in this line of work is on custom systems.