TL;DR: Whaticket: open source brasileiro focado em WhatsApp multiatendimento, com conexão via QR code (não oficial) no coração do produto, setup direto e comunidade local; herda os riscos do regime de pareamento (ban, quedas de sessão). Chatwoot: plataforma internacional de atendimento multicanal, mais madura em arquitetura e recursos, com WhatsApp oficial nativo e conexões não oficiais apenas via pontes; mais pesada de operar. Nenhum dos dois tem CRM de vendas com funil. Quem decide entre eles está escolhendo o sotaque da caixa de entrada; a categoria é a mesma, com as mesmas fronteiras.

O que cada um é, sem torcida

Whaticket (e seus muitos forks, que dominam o ecossistema de implantadores) é a resposta brasileira à pergunta “quero vários atendentes num número de WhatsApp, hoje”: filas, setores, transferência, mensagens rápidas, tickets, tudo desenhado em volta da conexão por QR code. A força é o foco: para operação 100% WhatsApp, o caminho até funcionar é curto e a comunidade local é abundante. A fragilidade é a fundação: o produto inteiro assenta sobre sessão não oficial, com os vetores de banimento e queda que valem para toda a família, como detalhamos em bloqueio de número em conexão não oficial.

Chatwoot é a plataforma de atendimento completa que mapeamos no guia do Chatwoot: multicanal (site, e-mail, sociais, WhatsApp oficial), arquitetura madura, relatórios, base de conhecimento. O WhatsApp por pareamento só entra via pontes externas (Evolution API e afins), com os atritos documentados. A força é a amplitude e a engenharia; o custo é operar uma aplicação Rails maior, com os requisitos e o ritual de atualização correspondentes.

A comparação que decide

Duas linhas merecem sublinhado. A dos forks: “Whaticket” na prática é uma família de projetos derivados com qualidade e manutenção muito desiguais; escolher o fork é tão importante quanto escolher a ferramenta. E a última linha: nenhum dos dois carrega funil de vendas com valor e etapa, a lacuna que analisamos em Chatwoot é um CRM? e que vale igual para o rival.

A resposta por perfil

Operação enxuta, só WhatsApp, tolerante ao risco do pareamento e com implantador de confiança: o Whaticket entrega mais rápido. Operação multicanal, com equipe técnica e disposição de operar via API oficial: o Chatwoot é o produto mais sólido. E o terceiro perfil, o mais comum entre quem chega a este artigo: operação comercial que vende pelo WhatsApp e quer contrato na conexão, funil na gestão e ninguém de plantão no sábado. Para esse, a resposta honesta é que a dupla do título é a escolha errada pelas mesmas razões, e a categoria certa é a plataforma conversacional com CRM sobre API oficial (com coexistência preservando o app, pela documentação da Meta de 2025): o desenho do Cubo Suite, interesse declarado.

Whaticket é seguro contra banimento?

Não: a conexão por QR code opera no regime não oficial, com risco de banimento permanente independente do capricho da instalação. É a mesma fundação da Evolution API e da Z-API, com as mesmas consequências.

Qual dos dois é mais fácil de instalar?

O Whaticket costuma chegar mais rápido ao “funcionando” para o caso WhatsApp puro; o Chatwoot exige a pilha completa (Rails, Sidekiq, PostgreSQL, Redis) e método. Facilidade de instalar não prediz facilidade de operar por dois anos: essa régua favorece quem tem menos peças e mais disciplina.

Algum dos dois tem CRM com funil de vendas?

Não nativamente: ambos são caixas de entrada de atendimento. Alguns forks de Whaticket incluem kanban simples de conversas, que organiza a fila, sem o modelo de oportunidade (valor, previsão, desfecho) de um CRM.

O post Whaticket ou Chatwoot? Os dois times estão certos (sobre problemas diferentes) apareceu primeiro em Blog Cubo Suite.

TL;DR: O Chatwoot conecta WhatsApp de duas formas: via Cloud API oficial da Meta (canal nativo do produto, com cadastro empresarial, templates e tarifas da tabela oficial: atendimento reativo gratuito, marketing a US$ 0,0625 por mensagem no Brasil desde julho de 2025) ou via ferramentas de pareamento (Evolution API com conector embutido, Z-API por ponte), sem burocracia de entrada e com os riscos conhecidos: banimento possível, mensagens do celular que somem do painel, dessincronia. Para operação comercial, a conexão oficial ganhou o desempate definitivo em 2025 com o modo coexistência: o aplicativo do celular continua funcionando junto da API.

Caminho 1: o canal oficial nativo

O Chatwoot traz o WhatsApp Cloud API como tipo de inbox nativo: você cadastra o número na plataforma da Meta (conta business, verificação, número dedicado), gera as credenciais e configura o canal no Chatwoot com token e webhook. A partir daí, o funcionamento é o contratual: mensagens de clientes chegam à caixa de entrada, respostas dentro da janela de 24 horas são livres e gratuitas, mensagens ativas fora da janela usam templates aprovados com as tarifas da tabela da Meta.

Os custos desse caminho são de cerimônia, não de risco: o cadastro empresarial leva dias, mensagens ativas dependem de template aprovado, e o número passa a operar sob as regras publicadas da plataforma. Em troca, não existe QR code, não existe sessão para cair, e não existe o vetor de banimento por automação: a automação é o serviço contratado.

Caminho 2: as pontes de pareamento

Quem quer evitar a cerimônia conecta por pareamento, e o ecossistema oferece duas rotas principais: a Evolution API, que traz conector de Chatwoot embutido (a rota mais montada do open source brasileiro), e a Z-API via ponte própria, para quem prefere a conexão como serviço. Nas duas, o número entra escaneando QR code, sem cadastro na Meta, e as conversas fluem em minutos.

O preço aparece nas três frestas documentadas publicamente: mensagens enviadas pelo celular que não aparecem no painel (issue #485 do repositório da Evolution API, entre outros relatos), remetente trocado em certas configurações (issue #8712 do Chatwoot) e o risco estrutural do regime: número pareado pode ser banido pela plataforma, e a sessão cai quando o protocolo muda. Para suporte interno tolerante a falha, é um trade aceitável; para o canal que fecha vendas, é operar o caixa da empresa num gerador emprestado.

O desempate que mudou em 2025: coexistência

Durante anos, o caminho oficial tinha um custo que empurrava todo mundo para o puxadinho: registrar o número na Cloud API significava perder o WhatsApp do celular. Quem mandava no argumento era o dono da empresa, que não abre mão de responder do bolso. Esse argumento expirou: o modo coexistência, documentado pela Meta (2025), conecta o número do WhatsApp Business à Cloud API mantendo o aplicativo ativo, com sincronização de até 180 dias de conversas individuais e eco das mensagens do app chegando ao sistema via webhooks documentados, exatamente a fresta número um do caminho 2, resolvida por desenho no caminho 1.

Requisitos e limites documentados: app na versão 2.24.17 ou superior, onboarding via parceiro da plataforma, grupos fora da sincronização, transmissões desativadas e vazão de 20 mensagens por segundo.

Qual caminho para qual operação

Para a última linha, o registro de interesse: montar Chatwoot + conexão + CRM + pontes para cada cliente é um projeto de integração contínuo, e a alternativa de plataforma única com API oficial nativa (incluindo coexistência), atendimento e CRM juntos é o Cubo Suite, inclusive white label para operar com a sua marca. O quadro completo do Chatwoot, forças e fronteiras, está no guia do Chatwoot.

O Chatwoot conecta WhatsApp por QR code nativamente?

Não: o canal nativo é a Cloud API oficial. Conexão por QR code entra apenas via ferramentas de terceiros (Evolution API, Z-API) integradas por conector ou ponte, com os atritos e riscos do pareamento.

Quanto custa o WhatsApp oficial no Chatwoot?

O Chatwoot não cobra pelo canal; as tarifas são da Meta, por mensagem desde julho de 2025: atendimento iniciado pelo cliente gratuito, utilidade gratuita na janela de 24h, marketing a US$ 0,0625 por mensagem no Brasil.

Dá para usar o mesmo número no app e no Chatwoot?

No pareamento, sim, com a instabilidade conhecida. No caminho oficial, o modo coexistência da Meta (2025) mantém app e API no mesmo número, com histórico individual sincronizado, os dois lados vendo a mesma conversa.

O post WhatsApp no Chatwoot: a porta da frente, o puxadinho e o desempate de 2025 apareceu primeiro em Blog Cubo Suite.

TL;DR: As três formas de pagar pelo Chatwoot: (1) self-hosted community: licença gratuita, custo real de R$ 100 a R$ 400 mensais de infraestrutura (premissa de mercado BR 2026) mais 2 a 6 horas mensais de operação e o plantão; (2) cloud oficial: mensalidade por agente na tabela do fornecedor, com infraestrutura e updates inclusos; (3) enterprise/recursos avançados: sob contrato. A resposta certa depende de uma variável só: existe alguém tecnicamente responsável pela instância? Sem essa pessoa, o “grátis” é a opção mais cara da lista.

Resposta 1: o self-hosted e a fatura invisível

A versão community é open source de verdade: sem licença, sem limite artificial de agentes, código no GitHub. A fatura chega por outras vias, todas dimensionadas nos artigos desta série: a máquina (piso de 4 GB de RAM; faixas completas em requisitos e custo de self-host), a instalação com método (o roteiro e as travas), o ritual de atualização (com os casos públicos de update que quebrou) e a linha sem número da planilha: quem atende o incidente de sábado.

Como premissa consolidada de operação estável: R$ 100 a R$ 400 de infraestrutura + 2 a 6 horas técnicas mensais. Com hora técnica a R$ 80, o “grátis” custa entre R$ 260 e R$ 880 por mês, sem contar picos de incidente. É competitivo? Depende do que se compara, e é aí que entram as outras duas respostas.

Resposta 2: a nuvem oficial paga

A empresa Chatwoot vende a versão hospedada com preço por agente/mês (consulte a tabela vigente no site oficial; valores mudam e não vale gravá-los aqui). O que a mensalidade compra: infraestrutura, atualização, backup e disponibilidade como problema deles. O que ela não muda: o produto continua sendo caixa de entrada de atendimento, com as fronteiras que mapeamos no guia do Chatwoot: sem CRM de vendas nativo, sem white label de prateleira, e WhatsApp via API oficial com as tarifas da Meta (atendimento reativo gratuito; marketing a US$ 0,0625 por mensagem no Brasil, tabela desde julho de 2025).

Para times de suporte sem equipe de infraestrutura, é a versão honesta do Chatwoot: paga-se o software como serviço e usa-se o que ele é.

Resposta 3: enterprise e a fronteira do grátis

O modelo open core coloca recursos avançados (SSO/SAML, auditoria, funcionalidades corporativas e os recursos mais recentes de IA) nas edições pagas. Para a maioria das PMEs brasileiras, a community basta funcionalmente; a fronteira aparece em requisitos corporativos e, relevante para um público específico, nas condições de rebranding, tema com dobras suficientes para artigo próprio: Chatwoot white label.

A tabela das três respostas

A quarta linha que a tabela não mostra

Falta uma linha na comparação, e ela é a mais importante para quem vende pelo WhatsApp: nenhuma das três modalidades entrega funil, kanban e automação comercial, porque isso não é o produto, como demonstramos em Chatwoot é um CRM?. Quem precisa do conjunto (atendimento + CRM + automação + WhatsApp oficial com coexistência) compara o Chatwoot mais o custo das peças que faltam contra plataformas que já nascem inteiras, e nessa prateleira mora o Cubo Suite, interesse declarado. A conta certa nunca é “grátis vs pago”: é o custo total da stack que resolve o seu problema inteiro.

O Chatwoot self-hosted tem limite de agentes?

Não há limite de licença na community: o limite é a máquina, e há relato público de lentidão severa com 10-15 usuários em instância subdimensionada (issue #3425). Agente adicional custa hardware, não licença.

Qual o custo do WhatsApp dentro do Chatwoot?

O canal oficial não tem custo do lado do Chatwoot; as tarifas são da Meta: serviço gratuito, utilidade gratuita na janela de 24h e marketing a US$ 0,0625 por mensagem no Brasil (tabela vigente desde julho de 2025).

Quando o self-hosted deixa de compensar?

Quando não existe responsável técnico com tempo alocado, ou quando a soma infra + horas + risco supera a mensalidade da alternativa. O sinal clássico da virada: instância congelada em versão antiga por medo de atualizar.

O post Quanto custa o Chatwoot: as 3 respostas corretas e a linha que falta na tabela apareceu primeiro em Blog Cubo Suite.

TL;DR: Requisitos realistas do Chatwoot self-hosted: 4 GB de RAM e 2 vCPUs como piso para equipes de até 5 agentes; 8 GB e 4 vCPUs para 10 a 20 agentes com movimento real (o relato público de lentidão com 10-15 usuários existe exatamente na faixa de quem economizou aqui); PostgreSQL e Redis com memória própria; disco crescendo com anexos e logs. O custo mensal de infraestrutura: R$ 100 a R$ 400 como premissa de mercado brasileiro em 2026, mais a linha dominante da planilha, que não é hardware: são as horas de quem opera.

O que consome o quê

A pilha do Chatwoot tem quatro consumidores com apetites diferentes. O Rails (web) serve painel e APIs, e escala com agentes simultâneos e websockets abertos: é ele que sente cada aba de atendente. O Sidekiq processa filas (e-mails, automações, webhooks) e sofre nos picos de campanha. O PostgreSQL guarda tudo e quer memória para não transformar cada busca de histórico em leitura de disco. O Redis segura cache e filas, pequeno mas inegociável.

A consequência prática: “instalei e ficou rápido” não prova dimensionamento, porque instalação vazia não exercita nenhum dos quatro. O teste honesto é segunda-feira de manhã com a equipe toda logada e o pico de conversas da semana.

Faixas de dimensionamento (premissas declaradas)

Trate como premissa de mercado, não cotação: provedores variam. O ponto estrutural que a tabela carrega: quem opera na faixa de baixo com carga da faixa de cima vira o relato da issue #3425, e a lentidão de painel em atendimento é custo por conversa, pago em tempo de cliente esperando.

Os custos fora da tabela de VPS

Backup testado. O banco carrega todo o histórico de atendimento da empresa; backup agendado e restaurado uma vez por trimestre (testado de verdade) é a diferença entre incidente e catástrofe. Custo baixo, disciplina alta.

Monitoramento e alerta. Uptime, disco, fila do Sidekiq. Fila crescendo em silêncio é o modo de falha favorito da pilha: tudo “funciona”, e nada acontece.

Horas de operação. A linha dominante: atualizações com método (o processo seguro está em como atualizar o Chatwoot), incidentes, ajustes. Como premissa de portfólio: 2 a 6 horas mensais em operação estável, com picos em release e incidente. Multiplique pela sua hora técnica e some à tabela: é essa soma que se compara com a mensalidade da cloud paga ou de uma plataforma pronta, conta que fazemos em quanto custa o Chatwoot.

O plantão. A linha que não tem número e decide mais que todas: quem olha quando cai no sábado? Em time técnico de verdade, é rotina absorvida. Em agência enxuta, é o medo silencioso que a planilha nunca mostra, e que já descrevemos no guia do Chatwoot: ser o único responsável por uma infraestrutura da qual clientes dependem tem um custo que só aparece quando cobra.

Para o perfil que soma essas linhas e não gosta do total, a alternativa estrutural, com infraestrutura, atualização e plantão do lado do fornecedor e API oficial do WhatsApp nativa, é o Cubo Suite, nosso interesse declarado.

Roda Chatwoot em VPS de 2 GB?

Sobe, para teste de conceito. Em produção, 2 GB estrangulam o conjunto Rails + Sidekiq + PostgreSQL + Redis nos primeiros picos, com sintomas de lentidão e fila travada. 4 GB é o piso honesto.

Posso dividir a VPS do Chatwoot com n8n e Evolution API?

Tecnicamente sim, e é arranjo comum por economia. O custo: as três aplicações dividem memória e o mesmo ponto único de falha; o reinício que resolve uma derruba as outras. Em produção com equipe, máquinas separadas (ou uma máquina generosa) pagam-se em incidentes evitados.

Quanto disco o Chatwoot consome?

Cresce com anexos de conversas e logs: operação com mídia intensa (fotos, áudios de clientes) consome gigabytes por mês. Storage externo (S3 compatível) para anexos é o ajuste que segura o disco da VPS no longo prazo.

O post Chatwoot self-hosted: requisitos reais e o custo que a tabela de VPS não mostra apareceu primeiro em Blog Cubo Suite.

TL;DR: Instalar o Chatwoot em VPS via Docker envolve: máquina com no mínimo 4 GB de RAM, Docker Compose com os serviços Rails, Sidekiq, PostgreSQL e Redis, variáveis de ambiente corretas (URL, SMTP, storage), migração de banco e proxy reverso com SSL. Os pontos onde as instalações travam, pelos relatos públicos da comunidade: Sidekiq sem processar filas (e-mails e automações param), SMTP mal configurado, assets do widget quebrando atrás do proxy e a migração de banco esquecida após updates. Reserve meio dia com método, não meia hora com sorte.

Antes de começar: a máquina certa

O Chatwoot roda Rails + PostgreSQL + Redis + Sidekiq, e cada peça quer memória. O piso confortável para equipe pequena: VPS dedicada com 4 GB de RAM e 2 vCPUs, sem dividir a máquina com outras aplicações pesadas. Abaixo disso, os sintomas são os clássicos: instalação que passa e operação que engasga. E o teto chega antes do que parece: a issue #3425 do repositório registra instância “muito lenta com 10 a 15 usuários”, lembrete público de que carga real pede dimensionamento real. Os números completos estão em requisitos e custo do self-host.

A instalação em seis passos (com os detalhes que travam)

1. Docker e Compose atualizados na VPS, com usuário não-root configurado e firewall liberando 80/443.
2. Compose oficial: parta do docker-compose do projeto, que sobe Rails (web), Sidekiq (worker), PostgreSQL e Redis como serviços separados. O detalhe que resolveu o caso da discussão #8954: Rails e Sidekiq em containers separados, cada um com sua responsabilidade, nunca um processo só fingindo ser os dois.
3. Variáveis de ambiente: FRONTEND_URL com o domínio definitivo (mudar depois dá trabalho), credenciais de banco, SECRET_KEY_BASE gerada, e SMTP completo. SMTP é o campeão de configuração adiada: sem ele, convites de agente e notificações morrem em silêncio.
4. Prepare o banco: rode a preparação/migração de banco antes do primeiro acesso. Guarde este comando na memória da operação: ele volta a cada atualização, e esquecê-lo tem consequência documentada (a discussão #5518 registra o caso clássico de “Account Suspended” após update, resolvido justamente rodando as migrações pendentes).
5. Proxy reverso com SSL: Nginx ou Caddy na frente, certificado válido, websockets habilitados (sem eles, a atualização em tempo real das conversas quebra de formas confusas).
6. Teste o circuito completo: criar conta, enviar e-mail de convite, plugar o widget numa página de teste, abrir conversa, responder. Só depois disso conecte canais reais.

Os quatro pontos de travamento clássicos

Sidekiq parado. Tudo parece funcionar, mas e-mail não sai e automação não roda: a fila não está sendo processada. Verifique o container do worker e a conexão dele com o Redis; é o primeiro lugar para olhar quando “funciona, mas não acontece nada”.

Widget com 404/500. Assets não compilados ou proxy sem os headers corretos. O sintoma aparece no site do cliente, o que o torna o mais constrangedor da lista.

E-mail que não envia. SMTP incompleto, porta bloqueada pelo provedor da VPS ou remetente sem autenticação. Teste com um e-mail real durante a instalação, não na primeira crise.

Atualização que quebra. Nova versão baixada, migração não rodada, edge cases de release (a v2.16.0 tem registro público de quebra de API e e-mail na discussão #6917). O método de atualização segura merece artigo próprio: como atualizar o Chatwoot sem quebrar.

Instalou. Agora começa a segunda conta

A instalação é o pedágio de entrada; a operação é a estrada. Backup do banco agendado e testado, monitoramento com alerta, rotina de atualização, e alguém nomeado para o incidente de sábado: sem esses quatro, a instância saudável de hoje é a surpresa de amanhã. É a parte da conta que o “grátis” não mostra no início, e que dimensionamos em quanto custa o Chatwoot de verdade. Para quem conclui que o pedágio vale a pena, o guia completo do Chatwoot mapeia o resto do caminho; para quem conclui que não, atendimento com CRM e API oficial nativa sem nenhuma dessas etapas é o que o Cubo Suite entrega pronto, interesse declarado.

Quanto tempo leva a instalação do Chatwoot?

Com experiência em Docker e o roteiro acima, meio dia incluindo testes. Os relatos públicos de semanas de luta vêm de ambientes fora do padrão e de configuração por tentativa: método encurta o caminho de forma dramática.

Dá para instalar Chatwoot em hospedagem compartilhada?

Não: a pilha exige Docker (ou instalação nativa Rails) com serviços persistentes, o que pede VPS ou servidor dedicado. Painéis como Plesk em ambientes com serviços conflitantes são fonte documentada de atrito.

Chatwoot ou a versão cloud paga?

Sem alguém para operar a instância, a cloud oficial paga elimina a conta de infraestrutura e atualização, pagando em mensalidade por agente. A régua está no nosso artigo de preços do Chatwoot.

O post Instalação do Chatwoot: Docker, VPS e os 4 pontos onde todo mundo trava apareceu primeiro em Blog Cubo Suite.

TL;DR: Chatwoot é uma plataforma open source de atendimento ao cliente: caixa de entrada compartilhada que unifica canais (site, e-mail, redes, WhatsApp via API oficial) para equipes responderem juntas, self-hosted ou na nuvem paga. O que ele entrega bem: conversas multiagente, automações de atendimento, base de conhecimento. O que ele não tem nativo: CRM de vendas com funil e kanban (a busca “chatwoot kanban” existe aos milhares porque a demanda existe e o recurso não), white label real e conexão de WhatsApp sem os requisitos da API oficial. O custo real do self-hosted: infraestrutura, atualizações que exigem cuidado e o plantão sendo seu.

Neste guia: o que é · a arquitetura por dentro · tour pelos recursos · o que faz bem · o que ele não é · da instalação ao 1º atendimento · custo real · Chatwoot vs vizinhos de prateleira · segurança e LGPD · erros de adoção · para quem serve · um cenário completo · glossário

O que é o Chatwoot?

Chatwoot é um software de atendimento ao cliente de código aberto, alternativa às plataformas comerciais de suporte: centraliza conversas de vários canais numa caixa de entrada compartilhada onde uma equipe atende com atribuição, notas internas, etiquetas e relatórios. Ele existe em duas formas: a versão cloud paga (hospedada pela empresa Chatwoot) e a versão self-hosted, que qualquer um baixa e roda na própria infraestrutura, a forma que domina o uso brasileiro pela combinação de custo zero de licença com controle dos dados.

A arquitetura é Ruby on Rails com PostgreSQL e Redis, madura e conhecida. E o modelo de negócio é o clássico open core: o código aberto cobre o essencial; recursos avançados moram na edição enterprise e na nuvem paga.

A arquitetura por dentro: as quatro peças que você vai operar

Quem hospeda o Chatwoot opera, na prática, quatro serviços, e cada um tem um jeito próprio de falhar. Conhecer o mapa antes encurta cada diagnóstico depois.

O Rails (web) é a aplicação principal: serve o painel, as APIs e os websockets que mantêm as conversas atualizando em tempo real na tela dos agentes. É a peça que sente cada agente logado, e a primeira a engasgar quando a máquina é menor que a equipe, o padrão do relato público de lentidão com 10-15 usuários (issue #3425).

O Sidekiq é o trabalhador de bastidor: processa filas de e-mail, automações, webhooks e tarefas agendadas. O modo de falha dele é o mais traiçoeiro do conjunto, porque nada quebra na tela: o painel funciona, e os e-mails simplesmente não saem, as automações não rodam. “Funciona mas não acontece nada” é Sidekiq até prova em contrário.

O PostgreSQL guarda tudo: contas, conversas, contatos, configurações. É o único componente cuja perda é irreversível sem backup, e o protagonista dos incidentes de atualização (as migrações de esquema que, esquecidas, produzem o famoso “Account Suspended” da discussão #5518).

O Redis sustenta cache, filas e o pub/sub dos websockets. Pequeno, essencial e frequentemente esquecido no dimensionamento: Redis sufocado aparece como lentidão generalizada difusa, sem culpado óbvio.

A consequência operacional do desenho: monitorar o Chatwoot é monitorar quatro processos e duas dependências, não “um site”. O checklist de operação da seção de custos parte daí.

Tour pelos recursos: o que existe dentro da caixa

O tour deixa visível o padrão que o guia inteiro repete: é um conjunto completo para atender, e nada na caixa gerencia vender. A tabela não tem linha de funil porque o produto não tem.

O que ele faz bem (a lista é séria)

• Caixa de entrada compartilhada com atribuição, times, etiquetas, notas privadas e visão de quem está atendendo o quê: o núcleo do produto, e é sólido.
• Multicanal real: widget de chat no site, e-mail, e canais sociais, com o WhatsApp entrando via Cloud API oficial da Meta como canal nativo.
• Automações de atendimento: regras de atribuição, respostas prontas, macros, chatbots via integrações.
• Relatórios de suporte: tempos de resposta, volume, CSAT.
• Código aberto auditável e dados na sua infraestrutura, argumento real para conversas de LGPD.

O que ele não é (e o mercado insiste em tentar)

Aqui mora a parte do guia que economiza meses de frustração. Três ausências definem a fronteira do produto:

Não é CRM de vendas. Não há funil, etapas de negociação, kanban de oportunidades, previsão de receita. A demanda brasileira por “chatwoot kanban” soma centenas de buscas mensais justamente porque quem opera vendas pelo WhatsApp bate nessa parede na segunda semana. As soluções da comunidade (plugins, integrações com CRMs externos) existem e têm custos próprios, tema que aprofundamos em kanban e CRM no Chatwoot, em Chatwoot é um CRM? e no improviso documentado de funil de vendas no Chatwoot.

Não é white label de prateleira. Remover a marca e revender como plataforma própria esbarra em limites técnicos e de licença que analisamos em Chatwoot white label: viável com engenharia e edição adequada, distante do “coloca meu logo e vende”.

Não conecta WhatsApp “fácil”. O canal nativo é a API oficial, com seus requisitos. Quem quer o atalho da conexão por pareamento acopla ferramentas de terceiros (Evolution API, Z-API) por pontes, com os atritos documentados que descrevemos em WhatsApp no Chatwoot.

Da instalação ao primeiro atendimento: o resumo executivo

O caminho completo, com as travas documentadas, está em instalação do Chatwoot; aqui vai o esqueleto para dimensionar o esforço. Máquina de 4 GB com Docker; Compose oficial subindo web, Sidekiq, PostgreSQL e Redis separados; variáveis de ambiente completas antes do primeiro start (URL definitiva e SMTP são as que todo mundo adia e paga); migração de banco; proxy reverso com SSL e websockets; e o teste do circuito completo (conta, convite por e-mail, widget, conversa, resposta) antes de conectar canal real.

Tempo realista com método: meio dia. O relato público de semanas de luta (discussão #8954) existe, e a diferença entre os dois números não é sorte: é seguir o Compose oficial em ambiente limpo em vez de adaptar a instalação a um servidor cheio de serviços conflitantes.

O custo real do self-hosted

A licença é gratuita; a operação, não. Os relatos públicos da própria comunidade dão as coordenadas do que esperar: instalação que pode consumir dias de tentativa (a discussão #8954 no GitHub do projeto documenta semanas de luta com Docker, filas do Sidekiq travadas e widget com erros), instância que exige recursos de verdade sob carga (a issue #3425 relata lentidão severa com 10 a 15 agentes), e atualizações que pedem método: há registro público de conta suspensa após update por migração de banco pendente (discussão #5518) e de release que quebrou funcionalidades (v2.16.0, discussão #6917). Nada disso desqualifica o projeto; tudo isso dimensiona o trabalho de quem o opera. O detalhamento por item está em instalação do Chatwoot, requisitos e custo de self-host e quanto custa o Chatwoot.

Chatwoot vs os vizinhos de prateleira

Contra os SaaS globais de suporte (Zendesk, Intercom e afins): o Chatwoot compete por custo e soberania de dados, e perde em polimento, ecossistema de apps e suporte contratual. Para equipes técnicas com orçamento curto, a troca costuma valer; para operações que precisam de fornecedor com SLA, não há edição community que substitua contrato.

Contra o ecossistema brasileiro de WhatsApp (Whaticket e forks): aqui a diferença é de natureza, não de qualidade: o Chatwoot é multicanal com WhatsApp oficial nativo; o Whaticket nasceu em volta do pareamento por QR code. O duelo completo, incluindo a linha dos forks, está em Whaticket ou Chatwoot.

Contra as plataformas conversacionais com CRM: essa é a comparação que a maioria dos avaliadores brasileiros deveria fazer e não faz, porque compara caixas de entrada entre si quando o problema é de vendas. Se as conversas terminam em “ganho/perdido”, a prateleira certa tem funil, automação comercial e atendimento no mesmo banco, a categoria que discutimos em Chatwoot é um CRM? e onde o Cubo Suite se posiciona, interesse declarado.

Segurança e LGPD: a soberania que vem com fatura de responsabilidade

O self-hosted entrega o argumento de LGPD mais forte da categoria: os dados de atendimento (conversas, contatos, anexos) ficam em servidor seu, sem suboperador estrangeiro na cadeia, com retenção e exclusão sob seu controle. Para contratos com áreas jurídicas exigentes, isso abre portas que SaaS global não abre.

A mesma frase, lida do outro lado, é a fatura: você vira o responsável técnico pela segurança desses dados. O mínimo profissional: TLS na borda e entre serviços quando separados; acesso ao banco restrito por rede; backups criptografados e testados (backup de conversa de cliente é dado pessoal em cópia); atualizações em cadência, porque instância congelada acumula vulnerabilidades conhecidas (o ritual seguro está em como atualizar o Chatwoot); e política de acesso ao painel, porque todo administrador enxerga todas as conversas. Agências que operam instâncias de clientes somam a camada contratual: papel de operador definido por escrito e aviso de privacidade do cliente final refletindo o arranjo.

Erros de adoção que custam caro (e nenhum é bug)

1. Adotar sem nomear o responsável. A pergunta “quem cuida da instância?” respondida com um cargo (“a equipe”) em vez de um nome é o preditor número um de instância abandonada em versão velha seis meses depois.

2. Esperar CRM da caixa de entrada. As 400 buscas mensais por “chatwoot kanban” são o custo coletivo desse erro. Defina antes da adoção onde vive o funil, ou a planilha paralela nasce na segunda semana.

3. Prometer white label sem ler as condições. Revender “plataforma própria” sobre rebranding cujas condições você não verificou é assinar passivo, como detalhamos em Chatwoot white label.

4. Dimensionar pela instalação, não pela carga. Instância vazia voa em 2 GB; segunda-feira com a equipe logada é outro produto. O relato de lentidão com 10-15 usuários é o memorial desse erro.

5. Conectar o WhatsApp pelo atalho errado para o caso. Ponte não oficial para canal de receita, ou burocracia oficial para projeto de teste: os dois desalinhamentos custam, cada um à sua maneira. A régua está em WhatsApp no Chatwoot.

Um cenário completo: o e-commerce que adotou certo (e esbarrou no teto certo)

Cenário declaradamente hipotético, com premissas explícitas, do uso que dá certo. Um e-commerce de suplementos com 4 agentes de atendimento adota o Chatwoot self-hosted: VPS de 8 GB (R$ 180/mês), um desenvolvedor da casa como responsável nomeado, canais de widget, e-mail e WhatsApp pela Cloud API oficial.

Mês 1: instalação em um dia, migração dos e-mails em uma semana, equipe treinada nas macros. Mês 3: a central de ajuda derruba 30% dos tickets repetitivos (premissa plausível para FAQ de logística); o CSAT integrado passa a pautar a reunião semanal. A operação de suporte está melhor do que no SaaS anterior, por um décimo do custo de licença. Mês 5: o comercial pede para usar “aquele sistema do atendimento” para o time de vendas B2B da empresa, e o responsável técnico faz a avaliação correta: conversas de venda precisam de etapa, valor e cobrança de follow-up, e etiquetas não entregam isso. O suporte fica no Chatwoot; a operação comercial vai para plataforma com CRM. Cada ferramenta na própria categoria.

A moral é a régua deste guia funcionando: o final feliz não veio de a ferramenta ser boa (ela é), veio do problema certo ter sido colocado dentro dela, com responsável, máquina e canal certos.

Glossário rápido

• Inbox: a representação de um canal (widget, e-mail, WhatsApp) dentro do Chatwoot; conversas nascem em inboxes.
• Agente: usuário de atendimento com acesso às conversas das inboxes em que trabalha.
• Sidekiq: o processador de filas da pilha (e-mails, automações, webhooks); quando trava, tudo “funciona” e nada acontece.
• Open core: modelo de negócio em que o núcleo é open source e recursos avançados moram nas edições pagas.
• Community edition: a versão self-hosted gratuita do Chatwoot, sem limite de agentes por licença.
• CSAT: pesquisa de satisfação pós-atendimento integrada aos relatórios.
• Cloud API: a API oficial do WhatsApp (Meta), canal nativo de WhatsApp do Chatwoot.
• Coexistência: modalidade da Meta (2025) que mantém o aplicativo WhatsApp Business ativo junto da Cloud API, com histórico individual sincronizado.
• Migração (de banco): alteração de esquema executada a cada atualização; esquecê-la é a causa clássica de instância quebrada pós-update.

Chatwoot para quem? A régua honesta

Para os dois últimos perfis, o interesse declarado desta casa: o Cubo Suite nasceu exatamente da fronteira que o Chatwoot não cruza: atendimento, CRM com funil, automação e construtor de páginas na mesma plataforma, com API oficial do WhatsApp nativa (incluindo o modo coexistência documentado pela Meta em 2025, que preserva o aplicativo no celular) e white label de verdade para agências. A comparação de quando cada caminho compensa está em Chatwoot para agências; o duelo clássico do ecossistema em Whaticket ou Chatwoot; e as rotas de saída por motivo em alternativas ao Chatwoot.

O Chatwoot tem aplicativo para celular?

Tem apps de agente para iOS e Android, que funcionam também com instâncias self-hosted corretamente configuradas (URL pública com SSL válido). A administração completa continua no painel web.

O Chatwoot faz disparo em massa no WhatsApp?

Não é a função dele: as campanhas do produto cobrem mensagens proativas em canais como o widget. Disparo ativo de WhatsApp em volume passa pelas regras da Cloud API (templates e tarifas da Meta), independentemente da ferramenta na frente.

O Chatwoot tem inteligência artificial?

As versões recentes trazem recursos de IA assistiva, com a divisão entre community e edições pagas mudando por release. Bots externos sempre puderam ser acoplados via API e integrações; a IA embutida é camada nova e convém conferir a matriz vigente antes de contar com ela.

Uma instância atende várias empresas ou marcas?

O Chatwoot suporta múltiplas contas na mesma instalação, o que tecnicamente permite servir vários clientes. Operacionalmente, todos dividem a mesma versão, a mesma janela de manutenção e o mesmo incidente, o ponto central da análise de Chatwoot para agências.

O Chatwoot é gratuito?

O código é aberto e a versão self-hosted não tem licença a pagar; o custo vira infraestrutura e operação. A versão cloud e a edição enterprise são pagas. A fronteira exata entre grátis e pago está em Chatwoot gratuito: até onde vai.

O Chatwoot funciona com WhatsApp?

Sim, nativamente via API oficial da Meta (Cloud API), com os requisitos e tarifas da plataforma. Conexões por pareamento entram apenas via ferramentas de terceiros, com pontes e atritos próprios.

O Chatwoot tem kanban ou funil de vendas?

Não nativamente: o produto é caixa de entrada de atendimento. Kanban e funil exigem extensões da comunidade ou integração com CRM externo, o motivo de “chatwoot kanban” ser uma das buscas mais comuns sobre a ferramenta.

Qual servidor preciso para rodar o Chatwoot?

Para equipe pequena, uma VPS dedicada com 4 GB de RAM é o piso confortável, com PostgreSQL e Redis; sob carga de dezenas de agentes, os relatos públicos indicam necessidade de dimensionamento bem maior. Os números estão no artigo de requisitos.

O post Chatwoot: o que é, o que entrega bem e as 3 fronteiras que ele não cruza apareceu primeiro em Blog Cubo Suite.

TL;DR: A community edition do Chatwoot cobre o núcleo completo do atendimento: caixa de entrada multicanal, agentes ilimitados por licença, automações, relatórios e API. Do lado pago (cloud e enterprise) moram: hospedagem gerenciada, recursos corporativos (SSO/SAML, auditoria), funcionalidades avançadas do modelo open core e condições de rebranding. As fronteiras que pegam de surpresa não são de licença: são operacionais (o custo de operar o grátis) e de produto (o que o Chatwoot inteiro, pago ou não, não faz: CRM de vendas e white label de prateleira).

O que a community entrega inteiro

Justiça primeiro, porque a versão gratuita é generosa: conversas ilimitadas, agentes sem limite de licença, canais múltiplos (site, e-mail, sociais, WhatsApp via Cloud API oficial), automações de atendimento, macros, times, relatórios operacionais, base de conhecimento e API completa. Para uma operação de suporte com alguém técnico cuidando da instância, dá para viver anos na community sem sentir falta de recurso pago, e há quem viva.

As três fronteiras do gratuito

Fronteira 1: operacional (a mais cara). Gratuito de licença, caro de operar sem preparo: a máquina dimensionada (requisitos reais), o ritual de atualização (com os casos públicos de quebra) e o plantão de quem responde quando cai. A conta consolidada, R$ 260 a R$ 880 mensais como premissa completa, está em quanto custa o Chatwoot. Essa fronteira não está escrita em nenhuma tabela de planos, e é a que mais derruba operações pequenas.

Fronteira 2: open core (a mais visível). O modelo de negócio do projeto reserva às edições pagas recursos corporativos e parte das funcionalidades avançadas (autenticação corporativa, auditoria, recursos recentes de IA e afins, conforme a divisão vigente no site oficial). Para PME, raramente é o bloqueio; para requisito corporativo, a conversa vira contrato.

Fronteira 3: de produto (a menos falada). Nenhuma edição, gratuita ou paga, transforma o Chatwoot no que ele não é: CRM com funil e kanban (a fronteira detalhada) ou plataforma revendável com a sua marca sem engenharia (o caso white label). Quem esbarra aqui não resolve pagando o enterprise: resolve mudando de categoria de ferramenta.

O teste de 10 minutos antes de decidir

Responda três perguntas por escrito, porque por escrito a resposta honesta aparece:

• Quem é a pessoa (nome, não cargo) que atualiza a instância e atende o incidente de fim de semana? Sem nome, a fronteira 1 já foi cruzada.
• Algum requisito corporativo (SSO, auditoria, compliance) está no horizonte de 12 meses? Se sim, orce o pago desde já.
• As conversas do WhatsApp terminam em “resolvido” ou em “ganho/perdido”? Se a segunda, a fronteira 3 é o seu caso, e o gratuito do Chatwoot não é a variável relevante da decisão.

O gratuito certo para o problema certo

A community edition é uma das melhores ofertas gratuitas do software de atendimento, para o problema de atendimento, operada por quem pode operá-la. As decepções documentadas na comunidade quase nunca vêm de promessa quebrada do projeto: vêm de expectativa importada de outra categoria, o suporte esperando SLA de fornecedor (a discussão pública “zero support”, #8954, é o retrato dessa expectativa encontrando a realidade do open source), ou a operação de vendas esperando CRM. O mapa completo do que esperar está no guia do Chatwoot; para quem descobriu neste teste que o problema é de vendas, a prateleira certa, com atendimento, CRM e WhatsApp oficial juntos, é o Cubo Suite, interesse declarado.

A versão gratuita do Chatwoot limita o número de agentes?

Não por licença: agentes ilimitados na community. O limite real é o hardware da instância, com relato público de degradação a partir de 10-15 usuários simultâneos em máquina subdimensionada.

O suporte do Chatwoot atende usuários da versão gratuita?

O canal da community é a própria comunidade (GitHub, Discord), sem SLA, e há registro público de frustração com tempos de resposta. Suporte com compromisso contratual é atributo das ofertas pagas, como em todo open core.

Quais recursos são exclusivos das versões pagas?

A divisão evolui com o produto: historicamente, autenticação corporativa (SSO/SAML), auditoria, recursos avançados de IA e condições de rebranding moram no lado pago. Consulte a matriz vigente no site oficial antes de decidir por um recurso específico.

O post Chatwoot gratuito: até onde vai a community edition (as 3 fronteiras) apareceu primeiro em Blog Cubo Suite.

TL;DR: Atualizar o Chatwoot sem quebrar exige um ritual de cinco passos: ler as notas da release (breaking changes são anunciadas), backup completo do banco imediatamente antes, atualizar a imagem em janela de baixo movimento, rodar as migrações de banco (o passo cujo esquecimento tem consequência documentada) e testar o circuito crítico antes de liberar a equipe. Pular releases acumulados exige atenção extra às migrações intermediárias. Congelar para sempre não é estratégia: é dívida com juros.

Por que atualização de Chatwoot dá medo (e o medo tem razão parcial)

O Chatwoot é uma aplicação Rails com banco relacional: cada versão pode alterar o esquema do banco via migrações. Quando o código novo sobe e a migração não roda, o desalinhamento entre código e banco produz comportamentos que parecem catástrofe (o caso público do “Account Suspended” é exatamente isso: o sintoma assusta, a causa é uma migração pendente, a correção é rodá-la). Some o histórico de releases com regressões pontuais, e o medo ganha lastro: atualizar sem método já quebrou produção de gente cuidadosa.

A resposta madura não é evitar a atualização: é industrializá-la.

O ritual de atualização segura

1. Leia as notas da release no repositório antes de qualquer comando. Procure por breaking changes, novas variáveis de ambiente exigidas e migrações pesadas. Cinco minutos de leitura evitam a noite inteira.
2. Backup do banco, agora. Não o backup de ontem à noite: um dump imediatamente antes da atualização, testável. É a sua única porta de volta real.
3. Janela de baixo movimento. Atualização com equipe atendendo é escolher o pior momento possível para descobrir uma regressão. Terça de manhã cedo vence sexta à tarde por goleada.
4. Suba a versão e rode as migrações. O par inseparável: imagem nova + migração de banco. Automatize os dois no mesmo procedimento documentado, para que a pressa de um sábado não pule o segundo.
5. Teste o circuito crítico antes de liberar: login, abrir conversa, responder, receber mensagem de canal real, e-mail de notificação saindo. Dez minutos de checklist contra horas de tickets internos.

Casos especiais que merecem respeito extra

Pulando muitas versões. Instância congelada há um ano não atualiza num salto: migrações intermediárias podem exigir passagem por versões específicas. Leia o caminho de upgrade recomendado, e considere ensaiar a sequência numa cópia do banco antes de fazer na produção.

Customizações e integrações. Cada personalização no código e cada ponte externa (a integração com Evolution API, os conectores de WhatsApp) é um ponto de conferência pós-update: APIs internas mudam, e o que era estável ontem versiona hoje. O mapa dos atritos de integração está em WhatsApp no Chatwoot.

Máquina no limite. Migração pesada em banco grande consome memória e tempo; VPS já sufocada (o cenário de requisitos apertados) escolhe a atualização como momento de cair. Confira folga antes.

O custo permanente que este ritual revela

Repare no que acabou de ser descrito: um procedimento de mudança com janela, backup, checklist e responsável, repetido a cada release relevante, para sempre. É trabalho de operação de software, e ele não aparece em nenhuma comparação de “grátis vs pago”. Quem tem equipe para isso, siga com orgulho: é assim que se opera open source com seriedade. Quem não tem acaba no pior dos mundos, a instância congelada com medo, e para esse perfil a conta honesta está em quanto custa o Chatwoot, incluindo a alternativa em que a atualização é problema do fornecedor: no Cubo Suite, versão nova chega instalada, e o sábado é seu. Interesse declarado.

Com que frequência devo atualizar o Chatwoot?

Acompanhe as releases e atualize em cadência regular (mensal ou bimestral), priorizando correções de segurança imediatamente. Quanto maior o intervalo, maior o salto e o risco acumulado do próximo update.

O que fazer se a atualização quebrar a instância?

Restaurar o backup feito no passo 2 e voltar à versão anterior é a rota de menor dano; depois, diagnosticar com calma (migração pendente é a primeira suspeita, com o caso público do “Account Suspended” como referência). Sem backup imediato, o diagnóstico vira corrida com a operação parada.

Posso automatizar a atualização do Chatwoot?

Automatize o procedimento (script com backup + imagem + migração + healthcheck), não a decisão: atualização autônoma sem leitura de release notes é roleta. O gatilho continua humano; a execução, script.

O post Como atualizar o Chatwoot sem quebrar: o ritual de 5 passos (e o preço de congelar) apareceu primeiro em Blog Cubo Suite.

TL;DR: A coexistência, documentada pela Meta (2025), permite registrar o número do WhatsApp Business na Cloud API oficial mantendo o aplicativo funcionando: é a combinação que o arranjo Chatwoot + ponte não oficial tentava imitar, agora com contrato. Para quem usa Chatwoot: o canal oficial nativo passa a receber também o eco das mensagens enviadas pelo app (webhooks documentados), o histórico individual sincroniza até 180 dias no onboarding, e as frestas clássicas da ponte (mensagem do celular sumida, remetente trocado, ban) saem do desenho. Requisitos: app 2.24.17+, onboarding via parceiro da plataforma; limites: grupos fora, transmissões desativadas, 20 mensagens/segundo.

O problema que a coexistência resolve para quem usa Chatwoot

O arranjo mais comum do Chatwoot brasileiro (ponte com Evolution API ou Z-API) existe por um único motivo histórico: era o jeito de ter o número no painel sem abrir mão do aplicativo. O custo desse arranjo está documentado nos próprios repositórios: mensagens do celular que não chegam ao painel, remetente invertido, dessincronia após updates, e o risco permanente de banimento do regime não oficial.

A coexistência ataca exatamente essa lista. Pela documentação da Meta: o número entra na Cloud API e o app permanece ativo; o que o dono responde pelo celular chega ao sistema conectado por webhooks de eco (que o sistema deve espelhar, por especificação); a importação inicial traz contatos e até 180 dias de conversas individuais na janela de 24h. O painel e o bolso passam a contar a mesma história por contrato, não por gambiarra bem ajustada.

Como fica a arquitetura com Chatwoot

O Chatwoot já possui o canal nativo de WhatsApp Cloud API. Com um número em coexistência, esse canal é o destino natural: as credenciais da Cloud API alimentam a inbox oficial, e a ponte não oficial se aposenta. Dois pontos de atenção práticos:

• O onboarding de coexistência passa por parceiros da plataforma (Solution Partners/Tech Providers, na nomenclatura da Meta): o fluxo de vincular o número do app à Cloud API é oferecido por plataformas parceiras, não por um botão avulso no painel da Meta. Na prática, você conecta através de quem implementa esse fluxo.
• O espelhamento do eco é responsabilidade do sistema conectado: a Meta entrega os webhooks; exibi-los correta e completamente na linha do tempo é trabalho da plataforma que recebe. Ao avaliar por onde conectar, teste especificamente esse caminho: mensagem enviada pelo app aparecendo no painel, com autor certo.

O que muda e o que se perde (lista da documentação)

Quem depende operacionalmente de grupos via API ou das listas de transmissão do app precisa pesar as duas linhas do meio antes de migrar: são as perdas reais do desenho, e é melhor descobri-las na tabela do que na segunda-feira seguinte.

Vale migrar o Chatwoot para coexistência?

Se o número é canal de receita: sim, e o argumento que segurava a decisão já não existe. A régua completa entre os dois regimes está em WhatsApp no Chatwoot. Vale também registrar a segunda pergunta, a que costuma aparecer três meses depois da primeira: se a operação é de vendas, a caixa de entrada regularizada continua sem funil, kanban e valor de negociação, a fronteira que mapeamos em Chatwoot é um CRM?. Para quem vai resolver as duas coisas de uma vez, conexão oficial com coexistência nativa, atendimento e CRM no mesmo banco é o desenho do Cubo Suite, interesse declarado desta casa.

O Chatwoot suporta o modo coexistência?

O Chatwoot opera o canal WhatsApp Cloud API; a coexistência é uma modalidade de registro do número nessa mesma Cloud API, com onboarding via parceiros da plataforma. O ponto a validar na sua implementação é o espelhamento completo dos webhooks de eco na linha do tempo.

Migro da Evolution API para a coexistência sem trocar de número?

Sim: a coexistência foi desenhada para levar o número existente do app à Cloud API. O histórico da sessão não oficial não migra; o do aplicativo sincroniza (até 180 dias de conversas individuais). O processo está no nosso guia de migração com coexistência.

As conversas de grupo aparecem no Chatwoot com coexistência?

Não: pela documentação da Meta, grupos ficam fora da sincronização e seguem existindo apenas no aplicativo. Operação dependente de grupos via API precisa pesar essa perda antes de migrar.

O post Chatwoot com API oficial e coexistência: a aposentadoria da ponte não oficial apareceu primeiro em Blog Cubo Suite.

TL;DR: A Z-API não declara publicamente qual biblioteca usa na conexão, e o site oficial (2026) não descreve a arquitetura; afirmar “usa Baileys” como fato seria ir além do que a empresa publica. O que é público: a conexão exige “um telefone com WhatsApp ativo”, o pareamento de dispositivo típico das conexões via protocolo do WhatsApp Web, a mesma família técnica do Baileys. Para efeito de risco (banimento, estabilidade, ausência de SLA da Meta), a família importa mais que a biblioteca: pareamento de dispositivo fora da API oficial carrega as mesmas consequências, seja qual for o código por baixo.

O que é o Baileys e por que ele virou régua

Baileys é a biblioteca open source que implementa o protocolo do WhatsApp Web por engenharia reversa, base do modo gratuito da Evolution API e de boa parte do ecossistema não oficial, história que contamos em Baileys: como funciona e por que está sendo bloqueado. Ele virou régua da categoria porque expôs o mecanismo: qualquer serviço que conecta um número via pareamento, sem passar pelo cadastro da API oficial da Meta, está operando um cliente web simulado, com ou sem o Baileys especificamente.

O que dá para afirmar sobre a Z-API (e o que não dá)

Fatos públicos: o site oficial da Z-API (2026) posiciona o serviço como API de WhatsApp com “mensagens ilimitadas” por tarifa fixa e lista como requisito um telefone com WhatsApp ativo. Não há, no material público, declaração de homologação da conexão junto à Meta nem descrição da biblioteca usada.

Leitura técnica, marcada como nossa: o requisito do telefone ativo com pareamento é a assinatura operacional das conexões via protocolo web. Se o motor específico é Baileys, um fork, ou implementação própria, é detalhe de engenharia interna que a empresa não publica, e para o cliente é quase irrelevante, porque as propriedades de risco vêm da categoria, não da biblioteca: a Meta não distingue “Baileys” de “implementação própria” ao detectar automação não homologada. Distingue conexão oficial de não oficial.

Por que essa distinção define o seu risco

Três consequências práticas valem para toda a família, e portanto para qualquer serviço com pareamento de aparelho:

• Banimento possível e permanente, com análise apenas pelo aplicativo, como detalhamos em banimento na Z-API. O fornecedor não tem canal junto à Meta para reverter.
• Estabilidade atrelada ao protocolo web: mudanças da Meta derrubam sessões da categoria inteira, independentemente do fornecedor.
• Ausência de contrato com a plataforma: o SLA que existe cobre a infraestrutura do fornecedor, nunca o vínculo com o WhatsApp.

A comparação completa entre os dois representantes mais buscados da categoria está em Evolution API vs Z-API, e a análise de risco da Z-API em particular em Z-API vale a pena?.

A pergunta que substitui “usa Baileys?”

A pergunta madura para 2026: “essa conexão é oficial ou não oficial?”, porque é ela que determina risco, regra e recurso. E, desde que a Meta documentou o modo coexistência (2025), a resposta oficial deixou de custar o aplicativo do celular: número na Cloud API com o app ativo e histórico individual sincronizado. Quem quer sair da categoria do pareamento encontra o caminho em Z-API ou API oficial com coexistência; a conexão pronta, dentro de plataforma com CRM e automação, é o que o Cubo Suite entrega, interesse declarado.

A Z-API confirma qual tecnologia usa?

Não em material público: o site descreve requisitos e recursos, não arquitetura. A ausência de declaração de homologação, somada ao pareamento por telefone ativo, sustenta a classificação na categoria não oficial, que é o que define o perfil de risco.

Se não é Baileys, o risco é menor?

Não de forma relevante. A detecção da Meta mira automação não homologada como categoria; implementações diferentes podem variar em detalhes de assinatura técnica, mas nenhuma ganha contrato, SLA ou canal de recurso por não usar uma biblioteca específica.

Existe API paga que seja oficial de verdade?

Sim: provedores e plataformas que operam sobre a Cloud API da Meta, com cadastro empresarial, templates e tarifas oficiais. O teste simples: conexão oficial não pede pareamento de aparelho, e mensagens ativas exigem template aprovado.

O post Z-API usa Baileys? O que é fato, o que é leitura e por que quase não importa apareceu primeiro em Blog Cubo Suite.