O problema de quem cuida do WhatsApp de dez clientes
No começo, cada cliente novo é resolvido do jeito que dá: um celular na gaveta do escritório, uma instância de uma ferramenta self-hosted num servidor pequeno, um número emprestado para testar o fluxo. Funciona até o quinto cliente. A partir daí aparecem os sintomas conhecidos:
- O cliente liga dizendo que o bot parou e você descobre que o aparelho desconectou há dois dias.
- Um número foi bloqueado e, na mesma semana, outros dois começaram a falhar no mesmo servidor.
- Ninguém sabe quanto o WhatsApp de cada cliente custa de verdade, então a mensalidade é chute.
- Cada fluxo no n8n tem uma credencial diferente, configurada à mão, sem padrão.
Nenhum desses problemas é de automação. São problemas de infraestrutura, e infraestrutura não é o que o seu cliente paga para ter. Ele paga pelo fluxo que qualifica lead, agenda visita ou cobra boleto. Uma API de WhatsApp gerenciada tira da agência a parte que ninguém vê e que mais dá trabalho.
Uma conexão por cliente, e cada uma no seu canto
O modelo que escala para agência é simples: cada cliente tem uma conexão própria, com nome previsível e webhook próprio. Nada de misturar dois clientes no mesmo número ou no mesmo processo.
| Tudo no mesmo servidor | Uma conexão isolada por cliente | |
|---|---|---|
| Número de um cliente bloqueado | Pode arrastar os outros que dividem IP | Afeta só aquele cliente |
| Conexão caiu | Alguém percebe quando o cliente reclama | Evento de status chega no seu webhook |
| Cliente cancelou | Sobra lixo de configuração no servidor | Você remove a conexão e pronto |
| Custo por cliente | Difícil de separar | Uma conexão, um valor fixo |
Na D-API, cada conexão roda em ambiente isolado, com as próprias credenciais, o próprio webhook e um proxy com IP único gerenciado pela plataforma. Quando um número de cliente toma bloqueio por causa de uma campanha mal planejada, os outros continuam trabalhando. Para entender o que costuma levar a bloqueio, e como evitar que o cliente cometa esses erros, leia como evitar banimento.
Como fica o onboarding de um cliente novo
O ideal é que colocar um cliente no ar vire rotina de dez minutos, igual para todos. Um roteiro que funciona bem:
- Defina o identificador. Use o nome do cliente como
sessionId, por exemplocliente-padaria-central. Esse nome aparece em todo evento e facilita achar o fluxo certo. - Crie a conexão já com o webhook. Aponte o
webhookUrlpara o nó Webhook do fluxo daquele cliente no n8n. - Conecte o número. Se o cliente está ao lado, QR Code. Se está longe, código de pareamento, que ele digita no celular sem precisar escanear nada.
- Teste com uma mensagem real para o número do responsável e confirme que o evento chegou no fluxo.
- Registre na sua planilha de carteira o identificador, o plano do cliente e o contato técnico dele.
Os passos 2 e 3 cabem em duas chamadas:
# cria a conexão do cliente, já apontando para o fluxo no n8n
curl -X POST https://api.d-api.cloud/api/v1/sessions \
-H "Authorization: SUA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"sessionId": "cliente-padaria-central",
"type": "unofficial",
"connectionMode": "pair",
"pairPhone": "5511999999999",
"webhookUrl": "https://n8n.suaagencia.com.br/webhook/padaria-central"
}'
# gera o código que o cliente digita no celular
curl https://api.d-api.cloud/api/v1/sessions/cliente-padaria-central/pair-code \
-H "Authorization: SUA_API_KEY"Quem tem muitos números por cliente, como uma rede com várias unidades, encontra o modelo de organização em múltiplos números no WhatsApp.
n8n: o que é nativo e o que passa por webhook
A maior parte das agências monta os fluxos no n8n. A D-API tem um community node, o n8n-nodes-d-api, que cobre as ações: enviar texto, mídia, lista, consultar dados. Ele é um nó de ação, não um gatilho. Para o fluxo reagir a mensagens recebidas, o caminho é o nó Webhook nativo do n8n, com a URL dele configurada como webhook da conexão do cliente.
Na prática, isso dá um padrão limpo: um fluxo de entrada por cliente, começando no nó Webhook, e os nós da D-API para responder. O passo a passo de instalação está na página da integração com n8n. Se o seu trabalho é mais de construir automações do que de gerir carteira, a página de API de WhatsApp para automação aprofunda esse lado. E, antes de desenhar os fluxos de entrada, vale entender o formato dos eventos em webhook de WhatsApp.
Operação sem babá: saber da queda antes do cliente
O que mais desgasta relação de agência com cliente é o cliente descobrir o problema primeiro. A D-API faz self-healing contínuo das conexões, e a maior parte das quedas se resolve sem ninguém agir. Para as que não se resolvem, o evento connection.status avisa com o valor connected, disconnected ou logged_out.
Um fluxo de monitoramento simples, que toda agência deveria ter:
- Ao receber
disconnected, espere alguns minutos e consulte a conexão de novo. Se continuar fora, mande um alerta para o grupo interno da agência. - Ao receber
logged_out, o cliente desconectou o aparelho ou trocou de celular. Gere um novo código de pareamento e envie para o responsável, com instrução de uma linha. - Guarde o histórico de quedas por cliente. Ele mostra quem precisa de orientação sobre uso do número.
Repasse de custo sem planilha de mensagens
Cobrança por mensagem é ruim para agência: o custo muda todo mês, depende de campanha que o cliente decide sozinho e obriga você a conferir extrato. Na D-API a cobrança é por conexão, não por mensagem. Um cliente, uma conexão, um valor que você sabe no dia da proposta.
E o preço por conexão fica mais barato conforme a carteira cresce, então a margem melhora a cada cliente novo em vez de apertar. Consulte as faixas em preços. Se o seu modelo é vender o próprio WhatsApp como produto, com a sua marca e a sua relação comercial, isso é revenda e tem outra conversa, descrita em API de WhatsApp para revenda.
Para validar o fluxo de onboarding com um cliente piloto, o trial é de 3 dias, sem cartão. Agências que também desenvolvem sistemas sob medida podem se interessar pela página de API de WhatsApp para software houses.
