Chamadas de voz no WhatsApp com baileys-caller

A Cloud API oficial cobre o envio e o recebimento de mensagens, templates aprovados, mídias e webhooks de status. Ela não expõe um endpoint para o seu backend discar uma chamada de voz para um número. Para alguns casos de uso (confirmar uma entrega por voz, fazer um callback automático de atendimento, disparar um alerta que precisa tocar como uma ligação), essa lacuna é um bloqueio real, e é aí que entram bibliotecas baseadas no protocolo do WhatsApp Web.

Baileys é uma biblioteca Node.js que fala o protocolo do WhatsApp Web via WebSocket. Ela não é a Cloud API oficial: roda em cima de uma sessão pareada (como se fosse o seu WhatsApp Web), o que abre portas que a API oficial fecha, mas também traz riscos que a API oficial não tem. O baileys-caller (https://github.com/SheIITear/baileys-caller) é um projeto focado em iniciar e gerenciar chamadas de voz e vídeo em cima dessa sessão Baileys.

O Baileys não usa HTTP REST como a Cloud API. Ele abre um WebSocket contra a infraestrutura do WhatsApp Web e mantém uma sessão autenticada, exatamente como o aplicativo WhatsApp Web faz no navegador. O pareamento acontece via QR code ou via pairing code (um código numérico digitado no celular). A partir daí, mensagens e eventos chegam por um fluxo de eventos assíncrono.

Seu backend (Node.js)
        |
   [Baileys socket]  <== WebSocket ==>  WhatsApp Web infra
        |                                       |
   credenciais da sessão                   celular pareado
   (auth state salvo)                       (QR / pairing code)
        |
   eventos: connection.update, messages.upsert, call

A sessão precisa ser persistida (o chamado auth state) para não exigir um novo pareamento a cada reinício. Os eventos mais relevantes são connection.update (estado da conexão), messages.upsert (mensagens) e os eventos de chamada, que são justamente o que o baileys-caller estende para permitir originar a ligação, e não apenas observá-la.

O código abaixo é ilustrativo. Ele mostra o padrão geral de conexão com Baileys, autenticação via pairing code e a ideia de iniciar uma chamada com o baileys-caller. Os nomes exatos de funções podem diferir da versão real do projeto, consulte sempre o repositório (https://github.com/SheIITear/baileys-caller) antes de usar em qualquer ambiente.

// ILUSTRATIVO: a API real pode diferir. Verifique o repo.
// https://github.com/SheIITear/baileys-caller
const { makeWASocket, useMultiFileAuthState } = require('@whiskeysockets/baileys');
// Import ilustrativo do helper de chamadas:
const { makeCaller } = require('baileys-caller');

async function start() {
  const { state, saveCreds } = await useMultiFileAuthState('./auth');

  const sock = makeWASocket({
    auth: state,
    printQRInTerminal: false,
  });

  sock.ev.on('creds.update', saveCreds);

  // Pareamento via pairing code (sem QR), informe o numero do bot:
  if (!sock.authState.creds.registered) {
    const code = await sock.requestPairingCode('5511999999999');
    console.log('Digite este codigo no WhatsApp do celular:', code);
  }

  // Camada de chamadas (ilustrativa):
  const caller = makeCaller(sock);

  return { sock, caller };
}

Com a sessão ativa, você inicia a chamada e trata os eventos de ciclo de vida. De novo, os nomes são ilustrativos: o importante é o padrão de tratar ringing, accepted, rejected e timeout.

// ILUSTRATIVO: nomes de metodos/eventos podem variar.
async function ligar(caller, destino) {
  // destino no formato JID do WhatsApp, ex: '[email protected]'
  const call = await caller.offerCall(destino, { video: false });

  call.on('ringing', () => console.log('Tocando no destino...'));
  call.on('accepted', () => console.log('Chamada aceita.'));
  call.on('rejected', () => console.log('Chamada rejeitada.'));
  call.on('timeout', () => console.log('Sem resposta (timeout).'));

  // Encerrar apos um limite, evitando chamada pendurada:
  setTimeout(() => call.hangup().catch(() => {}), 45000);
}

Usar uma biblioteca não oficial não é gratuito em termos de risco. O ponto mais importante: o WhatsApp pode banir o número usado, sem aviso e sem recurso prático. Trate isso como uma certeza eventual, não como uma possibilidade remota, e desenhe o sistema para sobreviver a ela.

• ToS do WhatsApp: originar chamadas via Baileys está fora dos termos de uso oficiais. Avalie o risco jurídico e de marca antes de seguir.
• Risco de ban do número: use um número dedicado e descartável, nunca o número principal do negócio ou um número pessoal.
• Instabilidade do protocolo: quando o WhatsApp muda o protocolo do Web, a biblioteca pode parar de funcionar até ser atualizada. Tenha um plano para indisponibilidade.
• Rate limit próprio: limite a frequência de chamadas (por minuto e por destino) para não parecer comportamento automatizado abusivo, que acelera o ban.
• Consentimento do destinatário: só ligue para quem aceitou receber chamadas. Chamadas não solicitadas geram denúncias, que também aceleram o ban.
• Sessão isolada: rode a sessão Baileys isolada, com auth state protegido, para conter o impacto se a credencial vazar.

A regra prática é simples: só use baileys-caller se o valor de negócio justificar o risco de ban e a manutenção contínua. Para produção crítica, prefira sempre um canal de voz oficial (telefonia, SIP, provedores de voz) e deixe o WhatsApp para mensagens via Cloud API.

• Use se: for um piloto, um caso de uso de baixo volume, com número dedicado e tolerância explícita a quedas e ban.
• Use se: o valor da chamada por voz no WhatsApp for alto o suficiente para compensar a infra e a manutenção contínua.
• NÃO use se: o fluxo for crítico para receita ou compliance e não puder tolerar indisponibilidade ou perda do número.
• NÃO use se: existir um canal de voz oficial (telefonia ou provedor de voz) que atenda o mesmo caso de uso com previsibilidade.
• NÃO use se: você não puder garantir consentimento do destinatário e rate limit responsável.

Se a decisão for seguir, contenha o risco com arquitetura. O objetivo é isolar a parte frágil e não oficial do resto do sistema, com fallback claro e observabilidade.

1. Isole a sessão Baileys em um worker dedicado, separado da sua API principal, com o auth state em armazenamento protegido.
2. Coloque as chamadas atrás de uma fila, para controlar concorrência, aplicar rate limit e nunca disparar tudo de uma vez.
3. Defina um fallback explícito: se a sessão Baileys cair ou o número for banido, caia para a Cloud API (mensagem) ou para SMS / telefonia.
4. Registre logging estruturado de cada chamada (destino mascarado, status, duração, motivo de falha) para auditar e detectar degradação cedo.
5. Monitore a saúde da sessão (connection.update) e alerte quando o pareamento cair, para reagir antes que a fila acumule.