Pular para o conteúdo

Projetos e fases

Referência do webhook: eventos, cabeçalhos, assinatura e novas tentativas

O contrato de cada entrega: eventos do catálogo, cabeçalhos x-aproova-*, como verificar a assinatura e quando o Aproova tenta de novo.

Para quem éProprietáriosAdministradores

Revisado em 14 de novembro de 2026

Antes de começar

  • Um webhook criado em Configurações > Integrações (proprietário do espaço, Fluxo ou superior) e o segredo de assinatura exibido no formulário.

Visão rápida da tarefa

Comece por estas etapas. Se a tarefa tiver outros passos, eles aparecem logo abaixo.

  1. Etapa 1

    Eventos do catálogo: review.created (revisão criada), review.version_uploaded (versão enviada), review.comment_created (comentário criado), review.verdict_submitted (decisão enviada por um participante), review.approved (revisão aprovada), review.rejected (revisão rejeitada), review.changes_requested (ajustes pedidos), review.approval_reopened (aprovação reaberta), review.unlocked (revisão desbloqueada). Aprovação reaberta e revisão desbloqueada só chegam aos webhooks que marcarem esses eventos; as assinaturas existentes continuam recebendo apenas os eventos que já tinham. O botão Testar envia o evento webhook.test.

  2. Etapa 2

    Cabeçalhos de cada entrega: x-aproova-event (tipo do evento), x-aproova-delivery (identificador da entrega), x-aproova-timestamp (segundos desde 1970, UTC) e x-aproova-signature. Também vão user-agent Aproova-Webhooks/1.0 e, quando há corpo, content-type application/json. Cabeçalhos personalizados não substituem esses nomes.

  3. Etapa 3

    Assinatura: x-aproova-signature = "sha256=" seguido do HMAC-SHA256 em hexadecimal, calculado com o segredo do webhook sobre o texto "${timestamp}.${body}", onde timestamp é o valor de x-aproova-timestamp e body é o corpo bruto recebido (texto vazio em GET, DELETE ou sem corpo). Calcule sobre os bytes recebidos, antes de converter o JSON, e compare em tempo constante.

Passo a passo

  1. 4Corpo padrão (JSON): event, event_id, created_at, workspace_id, locale e, quando existirem, proof, version, folder, teams, comment, decision, actor e whatsapp. Campos vazios são omitidos. O texto de comentários internos nunca é enviado.
  2. 5Campos opcionais de decisão: verification_method (authenticated_user, email_otp ou declared) e actor_verified (true só para authenticated_user e email_otp). Aparecem apenas em eventos de decisão que trazem essa evidência; em um corpo personalizado, use {{data.verification_method}} e {{data.actor_verified}}.
  3. 6Resposta: qualquer status 2xx conta como entregue. O Aproova espera até 6 segundos por resposta.
  4. 7Novas tentativas: falha de rede, tempo esgotado e os status 408, 425, 429 e 5xx são tentados de novo; outros status 4xx não. São no máximo 4 tentativas: a 2ª cerca de 5 minutos depois da 1ª falha, a 3ª cerca de 30 minutos depois e a 4ª cerca de 120 minutos depois. Depois da 4ª, a entrega fica como falha definitiva no histórico.
  5. 8Cada nova tentativa repete o mesmo event_id e o mesmo x-aproova-delivery. Use esse valor para ignorar repetições no destino. Se o espaço deixar de ter um plano com webhooks, a entrega falha sem nova tentativa.

O que deve acontecer

Seu serviço confere a assinatura, reconhece repetições pelo event_id e responde 2xx rapidamente.

Problemas comuns

  • Assinatura não confere: calcule sobre o corpo bruto, sem reformatar o JSON, e use o segredo atual (gerar um novo segredo invalida o anterior).
  • Ação duplicada no destino: uma resposta lenta ou um 5xx gera nova tentativa. Guarde o event_id já processado.
  • Evento novo não chega: marque aprovação reaberta ou revisão desbloqueada na lista de eventos do webhook.