Evolution API is probably the most widely used open-source project in the WhatsApp automation ecosystem, and the reason is simple: it solves in twenty minutes a problem that takes two weeks through the official route.
That is a genuine compliment, not a setup before the criticism. Before listing the risks, it is worth being clear about why so many competent people chose it.
Why it is so popular
To put a bot or an agent on WhatsApp through the official route, you need a Meta Business account, business verification, a number not already in use in the consumer app, templates approved before you can start any conversation, and a webhook with signature verification.
With Evolution API you start a container, open the QR code, scan it with your phone, and you are sending messages. Cost: your VPS. Timeline: an afternoon.
Add ready-made integrations with n8n, Typebot and Chatwoot, plus a large community, and it is obvious why it became the default for agencies, internal projects and MVPs, particularly across Brazil and Latin America.
What it actually is
This is the part that determines everything else, and plenty of teams use it for months without being clear on it.
Evolution API does not talk to Meta. It connects to WhatsApp as a linked device, exactly like WhatsApp Web. The QR code you scan is the same "link a device" mechanism from the app.
The direct consequence: from Meta's point of view, there is no API running. There is a phone with a linked device sending a lot of messages.
That explains every behaviour that confuses newcomers. Why the number can be banned. Why there is no verified business badge. Why there are no templates and no 24 hour window (Meta's rules simply do not apply, because Meta does not know you exist). And why, when something breaks, there is nobody to call.
What you accept along with it
No scaremongering, and nothing left out:
Meta's terms prohibit unauthorised clients. That is not interpretation, it is written down. Enforcement happens through number bans, usually triggered by user reports or by sending patterns. Plenty of people run for years without trouble. Others lose the number on their first campaign.
A ban takes the number, not the instance. If the banned number is your company's support line, what you lose is your customers' conversation history and the number printed on your cards, your website and your Google Business listing. Changing numbers costs more than it looks.
You own the uptime. Session dropped, container restarted, phone offline too long: you are the one who finds out and you are the one who reconnects. At three in the morning on a Saturday.
There is no support path. Not from Meta, because you are not their customer, and not from a vendor, because there is no vendor. There is a generous community, and it is genuinely good, but a community has no SLA.
Scale is the point where a pattern becomes a signal. One instance sending a few messages to people who wrote first looks like a person. The same instance sending a thousand messages in the morning does not.
The decision
| Your situation | Choose |
|---|---|
| MVP, prototype, validating an idea this week | Evolution API |
| Internal automation: alerts to your own team | Evolution API |
| Personal project, group bot, a tool for yourself | Evolution API |
| The number is your company's official support line | Official Cloud API |
| You are going to send campaigns or messages at volume | Official Cloud API |
| There is a contract, an SLA, or a customer paying for this | Official Cloud API |
| You need to start conversations with people who did not write first | Official Cloud API (it is the only one with templates) |
| Regulated sector, audits, traceability requirements | Official Cloud API |
| You want the verified badge and your business name showing | Official Cloud API |
The row that carries the most weight is the third from the bottom. Without approved templates, you can only reply to people who messaged you first. For support that may be enough. For appointment reminders, order confirmations, cart recovery or anything you initiate, it is not, and there is no legitimate way around it.
What each actually costs
Evolution API is free in the sense that the software is free. What it costs:
| Item | Evolution API | Cloud API via Zavu |
|---|---|---|
| Software licence | Free | Included |
| Server | Your VPS, and it has to stay up | Nothing to run |
| Per message | Free | Meta's rate passed through, no Zavu per-conversation fee |
| Keeping the session alive | Your job, indefinitely | There is no session to drop |
| Risk of losing the number | Real and uninsurable | Official account |
| Support when it breaks | Community | Vendor support |
Once you count the time of whoever babysits the instance, "free" usually costs more than the official account in any operation that already has paying customers. Below that line, Evolution API wins comfortably, and it is honest to say so.
The agent is the same either way
This is the reassuring part, and the reason the choice does not have to be permanent.
Your agent is a prompt plus tools. It does not know or care which channel delivered the message. Switching transport is not rewriting the agent, it is switching transport.
If you are on Evolution API today, the agent you wrote still applies. You do not port it by hand either. Install the skills and the CLI, then point your coding agent at the code you already have:
terminalnpx skills add zavudev/zavu-skills npx zavudev@latest login
> Here is my Evolution API bot. Move it to Zavu on the official WhatsApp Cloud API, keeping the same prompt and the same availability lookup. Deploy it and test with "do you have anything free on Thursday?"
What comes back:
TypeScriptimport { defineAgent, defineTool } from "@zavudev/functions" defineAgent({ senderId: process.env.SENDER_ID!, name: "Ana", provider: "zavu", model: "openai/gpt-4o-mini", prompt:) return res.json() }, })You are Ana, front desk for a clinic. Answer in two sentences or fewer. Never confirm a time without checking the calendar., }) defineTool({ name: "check_availability", description: "Get free appointment slots for a date. Use when the patient asks about scheduling.", parameters: { type: "object", properties: { date: { type: "string" } }, required: ["date"], }, handler: async ({ date }) => { const res = await fetch(https://clinic.example.com/slots?date=${date}
npx zavudev deploy and it answers on official WhatsApp, and on SMS, email and voice too if the sender has those channels. Same tool, same prompt.
The reverse also holds: if you want to keep Evolution API for internal use and run the official account for customer support, both can point at the same business logic. The tool is an HTTP function, and it does not care who called it.
How the migration goes
If you have decided to move to the official account, the path with the least pain:
The WhatsApp Business API integration guide covers the steps, and per-message pricing explained covers what Meta charges per conversation category, which is the calculation you want before deciding.
The honest summary
Evolution API is a good project solving a real problem, and the problem it solves is the bureaucracy of the official route. If you are validating an idea, automating something internal or building for yourself, use it and move on.
The moment to leave is when the answer to "what happens if this number is banned tomorrow" stops being "I get a new number" and starts being "the business stops".
Keep reading
- WhatsApp API: the complete guide: the official route explained from the start.
- WhatsApp Cloud API tutorial: step by step with code.
- WhatsApp per-message pricing: what Meta charges, by category.
- How to build an AI agent: the agent that runs on top of either one.