Skip to main content
Webhooks são a única forma de receber alguma coisa do WhatsApp: mensagens, recibos, mudanças de conexão. O Wabox faz um POST HTTPS com JSON para a URL que você configurar, uma URL por tipo de evento.

Configuração

No painel há dois lugares: Webhooks (menu lateral) define URLs e filtros para todas as instâncias do workspace, e a aba Webhooks e configurações gerais de cada instância permite sobrescrever só ali (desligue “Usar webhooks do workspace”). Instâncias novas herdam do workspace por padrão, e um workspace novo já começa no modo Uma única URL para todos os eventos (basta preencher a URL). Pela API, a configuração é sempre por instância:
Pode ser a mesma URL para tudo ou uma por tipo. null desliga o tipo. PUT /webhooks/{type} com { "value": "https://..." } altera um só. Os filtros decidem quais mensagens chegam. Para não repetir a URL em cada tipo, use o modo de URL única. Todos os eventos vão para single_url e as *_url por tipo são ignoradas. Roteie pelo type do corpo ou pelo header X-Wabox-Event; os ignore_*_callback continuam valendo:
use_workspace_webhooks (em GET /webhooks) diz se a instância está herdando a configuração do workspace. Definir qualquer URL não nula pela API desliga a herança automaticamente; envie { "use_workspace_webhooks": true } para voltar a herdar. Uma instância que herda assina as entregas com o secret do workspace (painel › Webhooks ou GET /account/webhooks), um só para todas as instâncias. Com configuração própria, vale o secret da instância.

Anatomia de uma entrega

Todo payload tem quatro campos em comum:

Garantias de entrega

  • Sem ordem garantida. As entregas saem em paralelo e cada evento tem as próprias tentativas, então um evento que falhou chega depois dos seguintes. Use momment e o estado que você já tem (ex.: não rebaixar um status de mensagem) em vez da ordem de chegada.
  • Tentativas. Você tem 10 s para responder 2xx. Qualquer outra resposta (incluindo um 502 do seu túnel ou proxy) ou o timeout contam como falha, e o Wabox tenta de novo após 10 s, 1 min, 10 min, 1 h e 6 h. Depois disso o evento é descartado e fica registrado como falha nos Logs de webhook do painel.
  • Pelo menos uma vez. Uma entrega pode repetir (por exemplo, você respondeu 200 depois dos 10 s, ou o seu proxy desistiu mas o backend processou). O event_id (também no header X-Wabox-Event-Id) é o mesmo em todas as tentativas. Guarde-o e ignore repetidos.
  • Sem conteúdo em repouso. O Wabox não guarda as mensagens que trafegam; se todas as tentativas falharem, a mensagem não é recuperável pela API (o histórico recente cobre só o que o celular enviou ao parear). Mantenha o endpoint disponível.
Responda antes de processar. Se o seu handler demora (chama outra API, grava em banco lento), coloque o evento em uma fila interna e devolva 200 na hora. Um endpoint lento vira reenvios, que viram duplicidade.

Segurança

Verifique X-Wabox-Signature em toda entrega. Ela prova que a requisição veio do Wabox e não de alguém que descobriu a sua URL. O passo a passo com código está em Assinatura dos webhooks. O segredo é o da instância ou, se ela herda os webhooks do workspace, o do workspace.

Testando

  • Sem servidor público: use um túnel (ngrok, Cloudflare Tunnel) apontando para a sua máquina.
  • Para ver o payload cru: qualquer serviço de “request bin”.
  • No painel, Logs de webhook mostra cada tentativa com status HTTP, tempo de resposta e o corpo enviado, e permite reenviar manualmente.
  • A aba Testes da instância dispara mensagens reais para um número seu e acompanha delivery e message_status. Veja Diagnóstico.