Saltar para o conteúdo principal
Os webhooks de alertas enviam os alertas da sua equipa para um endpoint HTTPS que você controla. Use-os para alimentar uma uma ferramenta de on-call, uma fila de tickets ou o seu próprio painel de operações. Os webhooks de alertas são separados dos webhooks de verificação. Os webhooks de verificação enviam os resultados de sessões, entidades e transações para a sua aplicação. Os webhooks de alertas indicam à sua equipa que algo precisa de atenção: uma verificação à espera de revisão, um pagamento falhado ou um incidente de serviço. Têm payload, segredo de assinatura, assinatura e calendário de tentativas próprios.

Configurar um destino

Configura os webhooks de alertas na Business Console, e não através da API. Os membros que podem gerir as definições da organização podem adicionar, alterar e testar destinos.
1

Adicionar o destino

Em Definições da organização > Notificações da equipa, adicione um destino Webhook de alertas com o URL do seu endpoint. O URL tem de usar https:// e resolver para um endereço público.
2

Guardar o segredo de assinatura

A Didit mostra o segredo de assinatura completo, que começa por whsec_, apenas uma vez. Guarde-o agora: depois disso, a consola mostra apenas os últimos quatro caracteres.
3

Encaminhar os alertas para o destino

Adicionar um destino não envia nada para ele. Adicione o destino às regras de encaminhamento dos alertas que quer que ele receba.
4

Enviar um teste

Clique em Enviar teste para enviar um alerta alert.test e confirme que o seu endpoint o aceita.
Uma organização pode ter até 25 destinos em Notificações da equipa. Só a atividade em produção chega a um destino. Os alertas sobre verificações em sandbox, verificações de empresas, transações e deteções AML nunca são enviados para ele.

Tipos de alerta

Payload

Cada alerta é um POST com um corpo JSON. A Didit envia o corpo como JSON compacto, com as chaves ordenadas. Este exemplo está formatado para facilitar a leitura:
data contém sempre:
  • event: a chave do evento, por exemplo session_in_review.
  • label e value: o que o alerta descreve, por exemplo Session e #1042.
Alguns tipos de alerta acrescentam chaves a data:
  • alert.billing.autorefill_failed acrescenta paused, um booleano que é true quando o carregamento automático fica agora pausado até atualizar o cartão.
  • alert.service.degraded e alert.service.recovered acrescentam service, status, incident_id, service_name, state, affected, country_name, started_at, resolved_at, duration_minutes, title e body. status é degraded ou down em alert.service.degraded, e recovered em alert.service.recovered. service usa as chaves de serviço de GET /v3/status/, e incident_id corresponde a um id de incidente nesse endpoint.
Os alertas nunca incluem dados pessoais nem dados de documentos do utilizador final. Identificam uma sessão, transação ou outro item pelo número e incluem uma ligação para o mesmo na consola. Ignore os valores de webhook_type e as chaves de data que não reconhecer, para que as novas não façam falhar o seu endpoint.

Cabeçalhos do pedido

Verificar a assinatura

X-Signature-V2 é o HMAC-SHA256 codificado em hexadecimal da cadeia <X-Timestamp>.<raw body>, usando o segredo de assinatura do seu destino como chave.
  • Utilize o segredo completo exatamente como a Didit o mostrou, incluindo o prefixo whsec_.
  • Assine os bytes brutos do pedido tal como os recebeu. Analisar o JSON e serializá-lo novamente pode alterar os bytes e fazer falhar a verificação.
  • Compare as assinaturas em tempo constante.
  • Rejeite um pedido cujo X-Timestamp tenha uma diferença superior a 5 minutos em relação ao seu relógio. A Didit assina cada tentativa, incluindo cada nova tentativa, com um timestamp novo, pelo que esta janela nunca rejeita uma nova tentativa legítima.
  • Em caso de falha da verificação, responda com 400. Uma resposta 401, 403, 404 ou 410 marca o destino para reconexão (ver Novas tentativas).
Os webhooks de alerta não são assinados da mesma forma que os webhooks de verificação. O cabeçalho também se chama X-Signature-V2, mas a cadeia assinada é diferente, e os webhooks de alerta não enviam X-Signature nem X-Signature-Simple. Não reutilize o verificador de webhooks de verificação.

Node.js (Express)

Python (Flask)

Renovar o segredo de assinatura

Renove o segredo no destino em Notificações da equipa. A Didit mostra o novo segredo uma única vez e assina todas as tentativas seguintes com ele, incluindo as novas tentativas de alertas criados antes da renovação. O segredo antigo deixa de funcionar imediatamente. Não há período de sobreposição, e nenhum cabeçalho transporta uma assinatura feita com o segredo anterior. Implemente o novo segredo no seu endpoint assim que o renovar.

Novas tentativas

A Didit considera qualquer resposta 2xx como entregue. Cada tentativa aguarda até 5 segundos pela sua resposta e não segue redirecionamentos. A Didit volta a tentar enviar um alerta após um tempo limite, uma falha de ligação, uma resposta 5xx, ou uma resposta 408, 425 ou 429. Faz até 5 novas tentativas, ao longo de cerca de 24 horas: Qualquer outra resposta é final, incluindo 3xx e qualquer outra 4xx. Um teste enviado com Enviar teste tem uma única tentativa e nunca é repetido. Uma resposta 401, 403, 404 ou 410 também marca o destino para reconexão: a consola mostra-o com o estado Voltar a ligar. Acontece o mesmo quando um URL resolve para um endereço privado ou bloqueado de outra forma no momento do envio pela Didit. A Didit continua a enviar novos alertas para o destino, e este volta a ficar ativo após a próxima entrega bem-sucedida ou quando atualizar o respetivo URL. Notificações recentes, em Notificações da equipa, listam cada entrega com o respetivo resultado, e pode tentar novamente uma entrega falhada a partir daí.

Relacionados

Última modificação em 7 de novembro de 2026