Configurar un destino
Los webhooks de alertas se configuran en la Business Console, no a través de la API. Los miembros que pueden gestionar la configuración de la organización pueden añadir, modificar y probar destinos.1
Añade el destino
En Organization settings > Team notifications, añade un destino Alert webhook con la URL de tu endpoint.
La URL debe usar
https:// y resolverse a una dirección pública.2
Guarda el secreto de firma
Didit muestra el secreto de firma completo, que empieza por
whsec_, una sola vez.
Guárdalo ahora: después, la consola solo muestra sus últimos cuatro caracteres.3
Dirige las alertas hacia él
Añadir un destino no hace que se le envíe nada todavía.
Añade el destino a las reglas de enrutamiento de las alertas que quieras que reciba.
4
Envía una prueba
Haz clic en Send test para enviar una alerta
alert.test y comprueba que tu endpoint la acepta.Tipos de alerta
Payload
Cada alerta es unPOST con un cuerpo JSON.
Didit envía el cuerpo como JSON compacto con las claves ordenadas.
Este ejemplo está formateado para facilitar la lectura:
data siempre contiene:
event: la clave del evento, por ejemplosession_in_review.labelyvalue: el elemento al que se refiere la alerta, por ejemploSessiony#1042.
data:
alert.billing.autorefill_failedañadepaused, un booleano que estruecuando la recarga automática queda pausada hasta que actualices la tarjeta.alert.service.degradedyalert.service.recoveredañadenservice,status,incident_id,service_name,state,affected,country_name,started_at,resolved_at,duration_minutes,titleybody.statusesdegradedodownenalert.service.degraded, yrecoveredenalert.service.recovered.serviceusa las claves de servicio deGET /v3/status/, eincident_idcoincide con elidde un incidente allí.
webhook_type y las claves de data que no reconozcas, para que los nuevos no rompan tu endpoint.
Encabezados de la solicitud
Verificar la firma
X-Signature-V2 es el HMAC-SHA256 codificado en hexadecimal de la cadena <X-Timestamp>.<raw body>, calculado con el secreto de firma de tu destino como clave.
- Usa el secreto completo tal como te lo mostró Didit, incluido el prefijo
whsec_. - Firma los bytes sin procesar de la solicitud tal como los recibiste. Analizar el JSON y volver a serializarlo puede cambiar los bytes y hacer que la comprobación falle.
- Compara las firmas en tiempo constante.
- Rechaza cualquier solicitud cuyo
X-Timestampdifiera en más de 5 minutos de tu reloj. Didit firma cada intento, incluido cada reintento, con una marca de tiempo nueva, así que esta ventana nunca rechaza un reintento legítimo. - Responde a una comprobación fallida con
400. Una respuesta401,403,404o410marca el destino para volver a conectarlo (consulta Reintentos).
Node.js (Express)
Python (Flask)
Rotar el secreto de firma
Rota el secreto en el destino, en Notificaciones del equipo. Didit muestra el nuevo secreto una sola vez y firma con él todos los intentos posteriores, incluidos los reintentos de alertas creadas antes de la rotación. El secreto anterior deja de funcionar de inmediato. No hay periodo de transición, y ningún encabezado incluye una firma hecha con el secreto anterior. Despliega el nuevo secreto en tu endpoint en cuanto lo rotes.Reintentos
Didit considera entregada cualquier respuesta2xx.
Cada intento espera hasta 5 segundos para recibir tu respuesta y no sigue redirecciones.
Didit reintenta una alerta tras un tiempo de espera agotado, un fallo de conexión, una respuesta 5xx o una respuesta 408, 425 o 429.
La reintenta hasta 5 veces, a lo largo de unas 24 horas:
Cualquier otra respuesta es definitiva, incluidas las
3xx y cualquier otra 4xx.
Una prueba enviada con Send test tiene un único intento y nunca se reintenta.
Una respuesta 401, 403, 404 o 410 también marca el destino para su reconexión: la consola lo muestra con el estado Reconnect.
Lo mismo ocurre con una URL que, en el momento del envío, se resuelve en una dirección privada o bloqueada por cualquier otro motivo.
Didit sigue enviando nuevas alertas al destino, que vuelve a estar activo tras la siguiente entrega exitosa o cuando actualizas su URL.
Recent notifications, en Team notifications, muestra cada entrega con su resultado, y desde ahí puedes reintentar una entrega fallida.
Relacionado
- Webhooks de verificación: resultados de sesiones, entidades y transacciones para tu aplicación.
- Estado del servicio: el feed público en el que se basan
alert.service.degradedyalert.service.recovered. - Revisión manual: qué hacer con una verificación en revisión.