Skip to main content
Os webhooks notificam seu sistema em tempo real sobre o que acontece em cada sessão do WhatsApp não oficial: mensagens recebidas e enviadas, mudanças de status, eventos de conexão, atualizações de chats/contatos e movimentações em grupos.

Configuração por sessão

Cada sessão tem sua própria configuração de webhooks, com dois modos de entrega:
Todos os eventos habilitados da sessão são enviados para a mesma URL. Útil quando um único endpoint concentra o processamento.
Cada evento tem sua própria webhookUrl, permitindo rotear eventos diferentes para endpoints diferentes.
Independente do modo, cada evento possui:
enabled
boolean
Liga ou desliga o envio do evento. Eventos desabilitados não são enviados.
webhookUrl
string
URL de destino do evento (no modo per_event) ou herdada da configuração única (no modo single).

Envelope comum

Todo webhook chega com o mesmo envelope. O conteúdo específico de cada evento fica em data.
event
string
required
Nome do evento (ex: messages.received).
sessionId
string
required
ID da sessão que originou o evento.
data
object
required
Conteúdo específico do evento. Veja a página de cada evento.
timestamp
string
required
Data e hora do envio em ISO 8601 (UTC).
traceId
string
Identificador para rastreamento ponta a ponta. Útil em logs e suporte.

Headers

Este produto não envia assinatura HMAC nos webhooks. Para restringir a origem, recomendamos usar uma URL secreta (com token no path) e/ou validar o User-Agent e o sessionId esperado.

Entrega e confiabilidade

Em caso de falha, a entrega é repetida até 7 vezes com backoff exponencial: aproximadamente 5s, 10s, 20s, 40s, 80s e 160s entre as tentativas.
Respostas HTTP 404 ou 410 são tratadas como falha permanente: a entrega não é mais retentada para aquela URL.
Cada tentativa tem timeout de 30 segundos. Endpoints lentos podem ser considerados falha e entrar em retentativa.
Há um circuit breaker por URL: URLs que falham repetidamente são temporariamente interrompidas para evitar sobrecarga.
Eventos passam por deduplicação via Redis (TTL de 5 minutos), reduzindo entregas duplicadas do mesmo evento em curto intervalo.
Responda rapidamente com um status 2xx. Faça o processamento pesado de forma assíncrona (fila/worker) e confirme o recebimento o quanto antes para evitar timeouts (30s) e retentativas desnecessárias.

Eventos disponíveis