Three ways to build a WhatsApp bot, and what each one costs you
Direct on the Cloud API, through a provider platform, or with an automation tool. What you trade in control, time and lock-in, and how to get out.
Rithul Palazhi11 min read
On this page
Worth stating first: CodeWords is one of the options described here, so this comparison has an interest in the outcome. What follows tries to be useful anyway, including about the situations where writing your own integration is the better decision.
There are three broadly different ways to put a bot on WhatsApp, and they differ less in what they can do than in what they cost you: engineering time, operational responsibility, monthly spend, and how hard it is to leave. Picking on features tends to produce the wrong answer, because at the level most businesses need, all three can do the job.
What we'll cover
The three approaches
Direct on the Cloud API. You register with Meta, run a webhook endpoint, handle messages yourself, and build everything above that.
Through a provider platform. A business solution provider or messaging platform sits between you and Meta, giving you an inbox, template management, flows and often an agent interface.
With an automation tool. You describe what should happen, the tool handles the platform mechanics and the connections to whatever else you use.
Every one of them ultimately talks to the same platform, obeys the same rules about templates and windows, and is subject to the same limits. The differences are entirely about who does which work.
Direct on the Cloud API
What you get. Complete control over behaviour, no intermediary in the data path, and no per-seat licence.
What you take on. A webhook endpoint that has to be available, because messages arrive whether you are ready or not. Retry and deduplication handling, since delivery is at-least-once and a duplicate order is a real outcome. Template submission and lifecycle. Media download and storage. Error handling for the specific failures the platform produces. Monitoring, so somebody knows when it stops.
Who it suits. Teams with engineers who will still be there in a year, unusual requirements, or a strong reason to keep the data path in-house.
The honest risk. It is usually a fortnight to a working prototype and considerably longer to something that survives, and the maintenance never ends. Plenty of businesses have a working prototype and an unmaintained production system, which is the worst of both.
Through a provider platform
What you get. Template management, an inbox humans can work in, routing and assignment, analytics, and often help with onboarding and verification.
What you take on. A per-seat or per-conversation cost that scales with the team, a product roadmap that is not yours, and a dependency in the middle of a customer channel.
Who it suits. Teams with several people answering messages, where the shared inbox and assignment are the actual requirement. That is a genuine product need and the reason this category exists.
The honest risk. It is easy to end up paying for an agent desk when what you needed was automation, and the two are priced differently.
With an automation tool
What you get. The platform mechanics handled, and the connections to your other systems as part of the same thing. Suits the case where the bot is mostly a front end onto work that has to happen elsewhere.
What you take on. A dependency, and a requirement that the tool can reach whatever you need it to reach.
Who it suits. Small teams without an engineer to spare, where the automation matters more than the agent desk.
The honest risk. If your requirement is genuinely a staffed inbox with routing and shift handover, this is the wrong category and a provider platform is the right one.
Building it with CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: what customers ask, what should be answered automatically, what should be collected, and what has to reach a person.
- Authorize the connections to your existing systems and your WhatsApp Business Platform account.
- Describe the exceptions, which is the work regardless of which of the three approaches you pick.
- Build the narrowest useful version first, so you find out what your customers actually send before committing to a shape.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What actually differs
Strip away the marketing and five things separate the approaches.
Time to something usable. Days, or weeks, or months, and the difference is mostly whose time.
Who is on call. Someone has to notice when messages stop arriving. Direct means you; the others mean a vendor and an escalation path.
Cost shape. Direct is engineering time plus message costs. The others add a subscription that usually scales with seats or volume.
Where the data goes. Direct keeps it in your systems. The others introduce a processor, which is a contract and a data protection question rather than a technical one.
How hard it is to leave, which is the one nobody weighs and the one that decides how the next three years feel.
Notice that none of those are capability. At the level most businesses operate, all three can build the same bot.
Who owns the number
The detail that causes the most pain later, whichever route you choose.
The business phone number and the Meta business portfolio should belong to your business, not to an agency, a contractor, or a vendor. A number registered under somebody else's portfolio is a number you may have to negotiate for, and a portfolio held in a departed employee's personal account is a genuine problem rather than an inconvenience.
Ask directly, before anything is set up: in whose portfolio does the number live, who holds administrative access, and what happens to both if the relationship ends. Get an answer you would be comfortable reading back in a year.
Migrating a number between providers is possible and it is a process rather than a click. Knowing that in advance changes how carefully you answer this question.
Getting out
Nobody evaluates on exit, which is exactly why exit costs are where lock-in lives.
Four questions to ask any vendor before committing.
Can I export conversation history, in a usable format, whenever I want.
Can I take the number with me, and what does that involve.
Do templates have to be recreated, or do they follow the account.
What happens to media stored in the platform.
If any answer is vague, that is the answer. The data you cannot recreate is the thing that keeps businesses on tools that stopped fitting two years ago.
How to decide
A short sequence that gets most people to the right answer.
Do several people need to answer messages, with routing and handover? If yes, you need an agent inbox, and that points at a provider platform regardless of everything else.
Is the bot mostly a front end onto other systems? If yes, an automation tool is the natural fit.
Do you have engineers who will still be here in a year, and a reason to keep the data path in-house? If yes, direct is viable and sometimes right.
Is this an experiment? Then optimise for how cheaply you can stop, not for how impressive it could become.
Most small businesses answer no, yes, no, and should stop reading comparison tables.
Making it survive
Own the number and the portfolio, in the business's name.
Keep at least two administrators.
Know your export route before you need it.
Review annually, since the right answer at two people differs from the right answer at ten.
Keep whatever you can in your own systems, so leaving is a migration rather than a rebuild.
Limits worth knowing about
All three obey the same platform rules. Templates, windows and limits do not change with the builder.
Per-message costs apply regardless, and they are not the part a vendor controls.
Building direct is a commitment to maintenance, not a one-off.
A tool nobody uses is worse than none, because your data is now in two places.
Capability is rarely the deciding factor, which is why feature comparisons mislead.
What to do first
Answer the inbox question. If several people need to answer messages with routing and handover, that single fact decides the category and you can stop comparing. If not, the choice is between an automation tool and building direct, and that is a question about engineering time rather than features.
Two habits make the difference. Put the number and the portfolio in your business's name before anything else is configured, because it is trivial now and an argument later. And ask the exit questions before signing rather than when you want to leave, since the answers do not improve with time.
Frequently asked questions
What are the three ways to build a WhatsApp bot?
Directly on the Cloud API, through a provider platform that sits between you and Meta, or with an automation tool that handles the platform mechanics and your integrations.
Does the approach change what the bot can do?
Rarely. All three obey the same rules about templates, the customer service window and messaging limits. The differences are time, cost shape, operational responsibility and exit.
When is building direct the right call?
When you have engineers who will still be there in a year, unusual requirements, or a strong reason to keep the data path in-house. It is a commitment to ongoing maintenance rather than a one-off build.
When is a provider platform right?
When several people need to answer messages with routing, assignment and handover. That is a real product need and the reason the category exists.
When does an automation tool fit?
When the bot is mostly a front end onto work happening in other systems, and there is no engineer to spare for webhooks and retries.
Who should own the phone number?
Your business, in your own Meta business portfolio, with at least two administrators. A number in an agency's or a departed employee's portfolio is a problem rather than an inconvenience.
Can a number be moved between providers?
Yes, and it is a process rather than a click. Knowing that in advance is a good reason to answer the ownership question carefully at the start.
What should I ask before signing?
Whether you can export conversation history in a usable format, whether the number can move, whether templates have to be recreated, and what happens to stored media.
What is the fastest way to decide?
Ask whether several people need to answer messages with routing and handover. If yes, you need an agent inbox. If no, the choice is about engineering time.
How often should the decision be revisited?
Annually. The right answer at two people is not the right answer at ten, and businesses tend to stay on whatever they picked first for far too long.