API de WhatsApp open source é de graça?

O software pode ser gratuito, a operação não. Servidor, proxies, monitoramento, backup e as horas de quem mantém tudo de pé entram na conta. Para poucos números o custo é baixo; com dezenas de clientes conectados, a operação vira um trabalho recorrente.

Quantos números dá para rodar num servidor próprio?

Depende do consumo de cada conexão e da arquitetura. O limite prático costuma aparecer antes na operação do que na máquina: quando várias conexões dividem processo e IP, um problema numa delas tende a afetar as outras.

Preciso de proxy para rodar WhatsApp no meu servidor?

Com poucos números, muitas operações rodam sem. Com muitos números saindo do mesmo IP de datacenter, cresce o risco de um comportamento suspeito afetar todos. Por isso operações maiores costumam dar um IP para cada conexão, o que exige comprar e gerenciar proxies.

Consigo migrar de uma solução self-hosted para uma gerenciada?

Sim. O trabalho principal é trocar as chamadas de envio e adaptar o receptor de webhook ao novo formato de evento. As conexões costumam ser refeitas lendo o QR Code de novo, então planeje a migração por lotes de clientes.

Quando faz sentido manter self-hosted?

Quando há exigência de que nada rode fora da sua infraestrutura, quando o volume é pequeno e estável, ou quando o seu time já opera esse tipo de serviço e quer controle total sobre versões e customizações.

API de WhatsApp self-hosted ou gerenciada?

A decisão que parece técnica, mas é de negócio

O primeiro número conectado num servidor próprio leva uma tarde. Um container, um QR Code e a mensagem sai. A dúvida aparece meses depois, quando o produto tem oitenta clientes e cada um tem o próprio WhatsApp. Aí a pergunta deixa de ser "funciona?" e vira "quem acorda quando cai?".

Existem projetos open source sérios e bem mantidos para isso, e eles resolvem o protocolo. O que eles não resolvem é a operação: manter dezenas de conexões estáveis, isoladas e observáveis, todos os dias. É essa parte que decide entre hospedar ou contratar uma API de WhatsApp gerenciada.

Custo total: o que entra na conta

O preço do servidor é a menor linha. A tabela abaixo lista o que costuma aparecer quando a operação cresce, sem valores, porque eles variam com a sua escala e com o custo do seu time.

Item	Self-hosted	Gerenciada
Servidores	Seu provedor de nuvem; cresce com o número de conexões	Incluído
IP por conexão	Comprar, rotacionar e trocar proxies	Incluído na D-API: cada conexão recebe IP único
Monitoramento	Montar alertas de conexão caída, fila e erro	Status da conexão via evento `connection.status`
Reconexão	Scripts próprios e intervenção manual	Self-healing contínuo
Mudanças do WhatsApp	Acompanhar releases, atualizar, testar, fazer deploy	Responsabilidade do fornecedor
Plantão	Alguém do seu time de sobreaviso	Suporte do fornecedor
Isolamento entre clientes	Depende de como você arquitetou	Cada conexão roda isolada, com credenciais e webhook próprios
Cobrança	Custo de infra mais horas do time	Por conexão, não por mensagem (ver preços)

A linha que mais pesa quase nunca aparece na planilha: as horas de engenharia que vão para manter a conexão viva em vez de evoluir o produto. Para um SaaS, manter WhatsApp de pé não é diferencial; é trabalho que o usuário final não vê.

O que dá trabalho de verdade no self-hosted

Reconexão e sessões que caem

Conexões de WhatsApp caem: o aparelho é trocado, a sessão é encerrada pelo celular, o protocolo muda. Cada queda precisa ser detectada, e cada sessão perdida exige avisar o cliente para ler o QR Code de novo. Sem isso, o cliente descobre sozinho, geralmente quando uma mensagem importante não saiu.

Efeito dominó

Quando todas as conexões rodam no mesmo processo e saem pelo mesmo IP, um número com comportamento ruim pode prejudicar os outros, e um vazamento de memória derruba todo mundo junto. Isolar por conexão resolve, mas é engenharia de infraestrutura que alguém precisa construir e manter.

Atualizações do protocolo

O WhatsApp muda sem aviso. Projetos open source costumam reagir rápido, mas a atualização ainda precisa chegar ao seu ambiente: ler o changelog, subir em homologação, testar envio e recebimento, fazer o deploy sem derrubar as sessões ativas.

Webhooks que não podem se perder

Se o seu receptor cai por um minuto, alguém precisa reenviar os eventos desse minuto. Na D-API, a entrega é repetida até 7 vezes com backoff; no self-hosted, essa lógica é sua. Os detalhes estão em webhook da API de WhatsApp.

Quando self-hosted faz sentido

Exigência regulatória ou contratual de que nenhum dado passe por infraestrutura de terceiros.
Volume pequeno e estável: poucos números internos, sem clientes dependendo deles.
Time de infraestrutura com folga e experiência em operar serviços com estado.
Necessidade de customizar o comportamento interno da biblioteca além do que uma API expõe.

Quando a gerenciada compensa

Cada cliente do seu produto tem o próprio número e a queda de um vira ticket de suporte.
O time de produto é pequeno e cada sprint gasto em infra atrasa o roadmap.
Você precisa provisionar conexões pela API, sem processo manual. Veja múltiplos números.
Você quer poder usar a API oficial no futuro sem reescrever a integração. Na D-API, oficial e não oficial usam o mesmo formato de chamada.

Checklist para decidir

Quantas conexões você terá em 12 meses?
Quanto custa uma hora do seu time de engenharia, e quantas vão para WhatsApp por mês hoje?
Qual o impacto de uma hora de WhatsApp fora do ar para o seu cliente?
Alguém do time topa ficar de plantão por isso?
Existe exigência que impeça usar infraestrutura de terceiros?

Se as respostas apontam para crescimento e pouca folga no time, a comparação seguinte é de preço. Comece por quanto custa uma API de WhatsApp e, se você tem um produto com vários clientes, pela página de API de WhatsApp para SaaS.

API de WhatsApp self-hosted ou gerenciada: quanto custa manter de pé