API de WhatsApp com múltiplos números em paralelo

Quando um número só deixa de bastar

Um número atende bem uma empresa pequena. O problema aparece quando a operação se divide, e cada parte precisa do próprio WhatsApp:

• Times diferentes. Vendas, suporte e financeiro com números separados, para o cliente saber com quem está falando e cada time ter a própria fila.
• Filiais e unidades. Cada loja, clínica ou franquia com o número que o cliente local já conhece, mas com os dados centralizados no mesmo sistema.
• Clientes de um software. O caso mais exigente: um CRM, um helpdesk ou um ERP em que cada cliente conecta o próprio número. Aqui são dezenas ou milhares de números, de donos diferentes.
• Distribuir volume. Operações que enviam muito dividem a carga entre números para respeitar o ritmo de cada um.

Em todos esses casos, o desenho da API de WhatsApp é o mesmo: uma sessão por número, e o seu sistema como a camada que decide quem fala por onde.

Uma sessão por número

Na D-API, criar mais um número é criar mais uma sessão. O sessionId é escolhido por você, então vale usar um identificador que já existe no seu banco, como o ID da filial ou do cliente. Cada sessão pode ter a própria URL de webhook desde a criação:

for unidade in centro zona-sul zona-norte; do
  curl -X POST https://api.d-api.cloud/api/v1/sessions \
    -H "Authorization: SUA_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{ \"sessionId\": \"filial-$unidade\", \"type\": \"unofficial\",
          \"webhookUrl\": \"https://seu-app.com/wa/filial-$unidade\" }"
done

Depois, cada unidade lê o próprio QR. Para listar o que existe na conta, use GET /api/v1/sessions; para ver o estado de uma sessão específica, GET /api/v1/sessions/{sessionId}. Em quem vende software, esse loop costuma virar parte do onboarding: o cliente se cadastra no seu produto, seu backend cria a sessão pela API e mostra o QR na tela, sem ninguém do seu time no meio.

Isolamento: por que um número não pode derrubar os outros

Rodar muitos números juntos cria um risco que não existe com um só: o efeito dominó. Se todos compartilham o mesmo processo, uma sessão travada consome recurso das outras. Se todos saem pelo mesmo IP, um número com comportamento ruim contamina a reputação dos vizinhos.

Na D-API, cada conexão roda isolada, com credenciais e webhook próprios, e recebe um proxy com IP único, gerenciado pela plataforma. Quando uma sessão cai, a reconexão acontece só nela. Para um SaaS, isso significa que o problema de um cliente continua sendo de um cliente, e não vira incidente geral com dezenas de tickets abertos ao mesmo tempo. Vale lembrar que isolamento reduz o estrago, mas não substitui boa prática de envio; as recomendações estão em como evitar banimento.

Webhook por sessão e roteamento

Há dois jeitos de receber eventos de muitos números, e os dois funcionam:

Dentro de cada sessão, dá para ir além e mandar cada tipo de evento para uma URL diferente, com a configuração por evento. Um exemplo comum é separar mensagens recebidas, que vão para o atendimento, de mudanças de status, que vão para o monitoramento:

curl -X POST https://api.d-api.cloud/api/v1/sessions/filial-centro/webhook-config \
  -H "Authorization: SUA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "type": "per_event",
    "events": {
      "messages.received": { "enabled": true, "webhookUrl": "https://seu-app.com/atendimento" },
      "connection.status": { "enabled": true, "webhookUrl": "https://seu-app.com/monitoramento" }
    }
  }'

No lado do seu sistema, o roteamento é uma consulta simples: dado o sessionId, qual cliente, qual fila e qual atendente. Guarde essa relação numa tabela e responda o webhook rápido; o processamento pesado fica numa fila sua.

O que monitorar quando são muitos números

• Status por sessão. Um painel com quantas sessões estão connected, quantas disconnected e quantas logged_out, alimentado pelo evento de status.
• Aviso ao dono do número. Quando uma sessão fica logged_out, quem precisa ler o QR de novo é o cliente ou a filial. Avise essa pessoa direto, pela sua interface ou por e-mail.
• Envio por sessão. Pare os envios automáticos de uma sessão que não está conectada, em vez de acumular erros.

Se o seu caso é o de software com um número por cliente, a página de API de WhatsApp para SaaS mostra o modelo completo. Para conectar cada número, veja conexão por QR code, e para estimar o custo com muitas conexões, a página de preços.