Procurando o lado de entrada — o webhook da Cloud API da Meta que entrega
mensagens do WhatsApp para a iZap? Esse é interno à conexão de WhatsApp da
própria iZap. O que está nesta página é a entrega de saída da iZap para o
seu endpoint.
Registrando um endpoint
url precisa ser https:// na porta padrão (443) — uma porta customizada
(ex.: https://exemplo.com:8443/hook) é rejeitada, assim como um endereço
privado ou de loopback, com 422. subscribed_events pode ficar
[] para receber todos os eventos do catálogo, inclusive os que forem
adicionados depois.
A resposta é o único lugar em que o segredo de assinatura aparece por
completo:
signing_secret imediatamente — não existe endpoint para lê-lo de
volta depois. Se você o perder, gire-o para obter
um novo.
Registrar um endpoint exige um plano que inclua webhooks de eventos. Sem
isso, a chamada retorna
403 com code: "plan_limit_event_webhooks".Catálogo de eventos
O catálogo é versionado apenas por adição — o formato dos eventos já
publicados não muda, então analisar o
message.received de hoje continua
seguro conforme novos tipos de evento forem adicionados.
Payload
Cabeçalhos
Uma entrega reenviada (automática ou manualmente) carrega o mesmo
izap-webhook-id e os mesmos bytes de payload, mas um novo
izap-webhook-timestamp e ambas as assinaturas recalculadas no momento do
envio. Só depois de verificar izap-webhook-signature-v2 é que
izap-webhook-id é seguro como chave de idempotência — a v2 assina o próprio
id, então uma entrega reenviada sob um id diferente falha na verificação.
Deduplique pelo id somente depois dessa verificação, nunca pelo timestamp ou
pela assinatura isoladamente: ambos mudam a cada nova tentativa e reenvio do
mesmo evento.
Verificando a assinatura
izap-webhook-signature-v2 é a verificação recomendada — é a única das duas
que cobre izap-webhook-id, o que fecha uma lacuna real: quem captura uma
entrega pode reenviá-la dentro da sua tolerância de timestamp sob um
izap-webhook-id novo, e uma verificação só com v1 continua válida, porque a
v1 nunca assinou o id. Também não existe outro identificador assinado
genérico no corpo para recorrer, e deduplicar por timestamp + assinatura não
ajuda — ambos são recalculados a cada nova tentativa e reenvio do mesmo
evento.
Legado: assinatura v1
izap-webhook-signature (v1=<hex-hmac>) continua sendo enviada em toda
entrega e não há plano de parar — integrações existentes continuam
funcionando sem mudanças. Ela não cobre izap-webhook-id, então sozinha
não distingue uma entrega reenviada sob um id novo de uma entrega
genuinamente nova; prefira
izap-webhook-signature-v2 em integrações
novas, e migre as existentes quando for conveniente.
Entrega e novas tentativas
- Seu endpoint tem 10 segundos para responder. Qualquer
2xxconta como entregue. - Respostas
5xxe429são reenviadas; qualquer outro4xxé tratado como rejeição definitiva e não é reenviado — retorne2xxsomente depois de aceitar o evento de forma durável. - Depois de 20 falhas consecutivas um endpoint é desabilitado
automaticamente (
enabled: false, comlast_errorpreenchido). Reative-o quando seu receptor estiver saudável novamente — ele não se recupera sozinho.
Gerenciando um endpoint
Girar o segredo invalida o anterior imediatamente — não há janela de
sobreposição, então atualize seu código de verificação com o novo segredo
antes de girar em produção. Um reenvio reproduz os bytes originais
armazenados, então ele verifica contra o mesmo payload da primeira tentativa.
Monte um receptor
izap-wizard webhook receiver grava um ponto de partida que já implementa
esse contrato para você.