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.Tipos de alerta
Payload
Cada alerta é umPOST 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 exemplosession_in_review.labelevalue: o que o alerta descreve, por exemploSessione#1042.
data:
alert.billing.autorefill_failedacrescentapaused, um booleano que étruequando o carregamento automático fica agora pausado até atualizar o cartão.alert.service.degradedealert.service.recoveredacrescentamservice,status,incident_id,service_name,state,affected,country_name,started_at,resolved_at,duration_minutes,titleebody.statusédegradedoudownemalert.service.degraded, erecoveredemalert.service.recovered.serviceusa as chaves de serviço deGET /v3/status/, eincident_idcorresponde a umidde incidente nesse endpoint.
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-Timestamptenha 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 resposta401,403,404ou410marca o destino para reconexão (ver Novas tentativas).
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 resposta2xx 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
- Webhooks de verificação: resultados de sessões, entidades e transações para a sua aplicação.
- Estado do serviço: o feed público subjacente a
alert.service.degradedealert.service.recovered. - Revisão manual: o que fazer com uma verificação em análise.