Saltar al contenido principal
Los webhooks de alertas envían las alertas de tu equipo a un endpoint HTTPS de tu propiedad. Úsalos para alimentar una herramienta de guardias, una cola de tickets o tu propio panel de operaciones. Los webhooks de alertas son independientes de los webhooks de verificación. Los webhooks de verificación envían a tu aplicación los resultados de sesiones, entidades y transacciones. Los webhooks de alertas avisan a tu equipo de que algo requiere atención: una verificación pendiente de revisión, un pago fallido, un incidente del servicio. Tienen su propio payload, secreto de firma, firma y calendario de reintentos.

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.
Una organización puede tener hasta 25 destinos en Team notifications. Solo la actividad en producción llega a un destino. Las alertas sobre verificaciones en sandbox, verificaciones de empresas, transacciones y coincidencias AML nunca se le envían.

Tipos de alerta

Payload

Cada alerta es un POST 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 ejemplo session_in_review.
  • label y value: el elemento al que se refiere la alerta, por ejemplo Session y #1042.
Algunos tipos de alerta añaden claves a data:
  • alert.billing.autorefill_failed añade paused, un booleano que es true cuando la recarga automática queda pausada hasta que actualices la tarjeta.
  • alert.service.degraded y alert.service.recovered añaden service, status, incident_id, service_name, state, affected, country_name, started_at, resolved_at, duration_minutes, title y body. status es degraded o down en alert.service.degraded, y recovered en alert.service.recovered. service usa las claves de servicio de GET /v3/status/, e incident_id coincide con el id de un incidente allí.
Las alertas nunca incluyen datos personales del usuario final ni datos de documentos. Identifican una sesión, una transacción u otro elemento por su número y enlazan a él en la consola. Ignora los valores de 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-Timestamp difiera 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 respuesta 401, 403, 404 o 410 marca el destino para volver a conectarlo (consulta Reintentos).
Los webhooks de alertas no se firman igual que los webhooks de verificación. El encabezado también se llama X-Signature-V2, pero la cadena firmada es distinta, y los webhooks de alertas no envían X-Signature ni X-Signature-Simple. No reutilices el verificador de tus webhooks de verificación.

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 respuesta 2xx. 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

Última modificación el 1 de noviembre de 2026