Você monta a campanha, sobe o criativo, o lead começa a chegar no WhatsApp, e no terceiro dia de disparo o número cai. Sem aviso. A metade da lista que ainda não recebeu a oferta fica pra trás, o link de checkout que ia junto na mensagem nunca sai, e você fica olhando pro QR code pedindo pra reconectar um número que o WhatsApp já decidiu banir. Aconteceu comigo com um chip de três anos de grupo aquecido. Aconteceu com metade das pessoas que rodam funil no WhatsApp.
Do outro lado tem o susto oposto: você vai pro caminho oficial da Meta pra nunca mais tomar ban, dispara uma campanha de marketing pra base inteira, e no fim do mês chega uma fatura que você não esperava, porque cada mensagem de marketing tem preço e ninguém te avisou direito quanto custa multiplicar isso por dez mil contatos.
Os dois sustos vêm da mesma decisão mal tomada: escolher entre Evolution API, Cloud API e Baileys sem entender que elas não são três versões da mesma coisa. São três apostas diferentes, com moedas de pagamento diferentes. Uma você paga com dinheiro. A outra você paga com risco de perder o número no pior momento possível.
A resposta curta: você paga com dinheiro ou com risco
Antes de descer no detalhe, a decisão em uma frase. Baileys é uma biblioteca não-oficial que finge ser o WhatsApp Web pra falar com o protocolo do WhatsApp por baixo. Evolution API é uma camada open-source que embrulha o Baileys numa API REST confortável, com multi-instância e webhook, então ela herda o risco do Baileys porque é o Baileys por baixo. Cloud API é o caminho oficial da Meta: você paga por mensagem, passa por verificação, e em troca não toma ban por usar automação.
Então a pergunta não é "qual é a melhor". É: o seu caso aguenta perder o número no meio de uma campanha? Se aguenta, Evolution/Baileys sai barato. Se não aguenta (conta de cliente, notificação transacional, operação que não pode parar), o preço da Cloud API é o seguro que você paga pra dormir tranquilo.
Evolution API vs Cloud API: o que cada uma é de verdade
O erro que mais vejo é tratar as três como concorrentes no mesmo nível. Elas vivem em camadas diferentes da pilha. Vamos por baixo pra cima.
Baileys: o protocolo não-oficial, cru
Baileys é uma biblioteca em TypeScript que implementa por engenharia reversa o mesmo protocolo que o WhatsApp Web usa. Ela não passa por servidor nenhum da Meta autorizado a fazer isso: ela finge ser um navegador com WhatsApp Web aberto. Funciona, é grátis, e é exatamente por isso que carrega o risco. Usar Baileys viola os termos de uso do WhatsApp, e a Meta persegue essas conexões de forma ativa. Quando ela identifica o padrão, bane o número, muitas vezes de forma permanente e sem aviso.
Não existe SLA, não existe suporte, não existe "abrir um chamado". Se cair, você reconecta escaneando o QR de novo e torce. É a ferramenta certa pra prototipar, pra automação interna de baixo volume, pra testar uma ideia. É a ferramenta errada pra pendurar o faturamento inteiro nela sem plano B.
Evolution API: a camada confortável sobre o Baileys
Ninguém quer escrever código de socket direto no Baileys. A Evolution API resolve isso: é uma API REST open-source, roda em Docker, e te dá endpoints limpos pra criar instância, mandar mensagem, receber evento. O ganho de verdade dela pra quem opera funil é o multi-instância (vários números na mesma instalação) e o webhook por instância, onde cada número dispara eventos pra uma URL sua com o que chega e o que sai.
Na configuração de webhook você escolhe os eventos que quer, tipo MESSAGES_UPSERT (mensagem nova), CONNECTION_UPDATE (o número conectou ou caiu) e QRCODE_UPDATED. É esse CONNECTION_UPDATE que deixa você saber que o número caiu na hora, em vez de descobrir de manhã pelo cliente reclamando. E é no MESSAGES_UPSERT do primeiro contato que chega o ctwa_clid de quem veio de um anúncio Click to WhatsApp, quando ele vem (o detalhe de por que o UTM se perde ao abrir o WhatsApp e como recuperar a origem do lead eu destrinchei em outro post). Se o webhook não estiver chegando, o problema quase nunca é a Evolution: é a cadeia de configuração do webhook que não dispara, e vale debugar antes de trocar de arquitetura.
O ponto que confunde todo mundo: a Evolution API na prática, no modo que a maioria usa, conecta via Baileys. Ou seja, ela é conforto de API por cima do mesmo risco de ban do Baileys. Ela não te protege do ban, ela te dá uma casca melhor pra trabalhar. A versão 2 dela também sabe falar Cloud API oficial como tipo de conexão, o que é ótimo pra migrar depois sem reescrever o seu lado, mas isso é uma opção que você liga, não o padrão que vem no tutorial de VPS que você seguiu.
Cloud API: o caminho oficial e pago da Meta
A Cloud API é a WhatsApp Business Platform hospedada pela própria Meta. Aqui muda tudo. Você não escaneia QR code: você registra um número dedicado, que não pode estar ativo no app do WhatsApp ao mesmo tempo e não pode estar amarrado a nenhuma conta pessoal ou Business existente. Você precisa de um Meta Business verificado, com documento de empresa (a verificação leva de 2 a 10 dias úteis), 2FA obrigatório desde 2024, e um nome de exibição que siga as regras da Meta.
Em troca dessa burocracia toda você ganha a única coisa que Baileys não te dá: legitimidade. Usar automação aqui não é violação de termo, é o produto. O número não cai porque você disparou muito rápido. O preço disso é literal, e mudou.
O custo da Cloud API mudou em julho de 2025 (leia antes de levar susto)
Até meados de 2025 a Meta cobrava por conversa (uma janela de 24 horas). Desde 1 de julho de 2025 a cobrança é por mensagem, e o preço depende da categoria do template. São quatro categorias, e a diferença entre elas é a diferença entre uma fatura tranquila e uma fatura assustadora:
- Marketing: oferta, promoção, recuperação de carrinho, reengajamento. É a categoria mais cara, e é justamente a que o operador de funil mais quer mandar. Cada mensagem de marketing tem preço, e multiplicado pela sua base inteira é onde mora o susto.
- Utility (utilidade): confirmação de pedido, aviso de pagamento, atualização transacional. Mais barata, e com faixas de preço que caem conforme o volume sobe.
- Authentication (autenticação): código de verificação, OTP, login.
- Service (atendimento): resposta dentro da janela de 24 horas que o cliente abriu ao te mandar mensagem primeiro. Essa não é cobrada. E template de utility enviado dentro dessa janela também sai de graça.
Traduzindo pra decisão de venda: se o cliente te chama primeiro (veio do anúncio, do site, do grupo) e você responde na mesma janela de 24 horas, é barato ou grátis. Se é você quem inicia a conversa fria com uma mensagem de marketing pra base inteira, aí sim cada mensagem tem custo, e é esse cenário que precisa entrar na conta antes de você apertar enviar. O número exato por mensagem de marketing no Brasil muda com o tempo e com a política da Meta, então confira a tabela oficial na hora de fechar a conta, mas a ordem de grandeza é centavos de dólar por mensagem: barato na unidade, relevante quando multiplica por dezenas de milhares.
O quadro de decisão honesto
Não existe resposta universal. Existe a resposta pro seu caso. Passa por essas perguntas na ordem:
| Sua situação | Escolha que costuma fazer sentido |
|---|---|
| Volume baixo, número seu, tolera reconectar se cair, quer testar rápido | Evolution API (Baileys) |
| Conversa comercial 1 a 1, atendimento, seu próprio grupo, orçamento apertado | Evolution API (Baileys) |
| Notificação transacional que NÃO pode falhar (pagamento, entrega, código) | Cloud API |
| Conta de cliente, onde perder o número é perder o cliente | Cloud API |
| Marketing em escala pra base grande, com previsibilidade de fatura | Cloud API (com custo calculado antes) |
| Operação que não pode parar por nenhum minuto, sem plano B manual | Cloud API |
Repare no eixo real da tabela: não é técnico, é de risco de negócio. Quanto mais o número banido custa pra você (cliente perdido, operação parada, dinheiro na hora), mais a Cloud API compensa apesar de mais cara e mais chata de configurar. Quanto mais você aguenta um tombo e reconectar, mais o Baileys via Evolution paga a conta com folga.
O que dá errado (a seção que separa isso de panfleto)
Erro 1: escolher Baileys pra escalar e tomar ban no meio da campanha. É o clássico. Funciona lindo no teste com 50 contatos, você anima, dispara pra 8 mil, e o padrão de volume alto mais falta de interação natural acende o alarme da Meta. O número cai com a campanha no ar, e o pior é o timing: você já pagou o tráfego que trouxe o lead, o lead está quente, e a mensagem que fecha a venda não sai. O prejuízo não é "perdi um chip", é "perdi as vendas que aquele tráfego pago já tinha comprado".
Erro 2: escolher Cloud API sem entender o custo por template e levar susto na fatura. O oposto. Você faz tudo certo no oficial, dorme tranquilo quanto a ban, e dispara marketing pra base inteira sem separar o que é marketing (pago) do que dava pra mandar como utility ou dentro da janela de atendimento (barato ou grátis). No fim do mês a fatura chega multiplicada pela categoria mais cara, em cima do volume inteiro, e o seguro que você contratou vira despesa que come a margem.
Erro 3: achar que Evolution API te protege do ban. Ela melhora sua vida de operação (multi-instância, webhook, monitoramento), não seu risco de protocolo. Enquanto conectar por Baileys, o risco é o do Baileys. Trocar de biblioteca de disparo não muda o que a Meta enxerga do outro lado.
Erro 4: não ter monitoramento de conexão. Vale pra qualquer escolha via Evolution: se você não escuta o CONNECTION_UPDATE e não tem um alerta quando o número desconecta, você vira o Marcos que descobre de manhã, com metade da régua de follow-up não entregue. A arquitetura escolhida muda o risco de cair, mas nenhuma delas te avisa sozinha: isso é você que instrumenta.
O caminho que eu recomendo na prática
Se você está começando e o número é seu, comece na Evolution API com Baileys, mas trate como o que é: barato e mortal. Nunca dependa de um único número, nunca dispare frio em escala, e instrumente o CONNECTION_UPDATE desde o primeiro dia. Quando a operação virar algo que não pode parar (conta de cliente, transacional, volume sério de marketing), migre a parte crítica pra Cloud API e deixe o Baileys só pro que aguenta cair.
O jeito de fazer isso sem reescrever tudo é manter uma camada de estados no meio: o seu sistema decide em que ponto da venda o contato está (chegou, respondeu, comprou, abandonou) e só então escolhe por qual canal falar. É exatamente essa máquina de estados de venda por cima da Evolution API que eu montei no Whatspix, justamente pra que a troca de Baileys pra Cloud API seja uma decisão de configuração, não uma refatoração no meio de uma campanha rodando. A arquitetura certa é a que te deixa mudar de aposta sem parar de vender.
No fim, "Evolution API vs Cloud API vs Baileys" não é uma escolha de ferramenta, é uma escolha de quanto o seu número banido custa. Responde isso com honestidade e a decisão se resolve sozinha.