Didit no envía un correo cuando una verificación cambia de estado: configura un webhook, suscríbete a los eventos y verifica la firma antes de confiar en él.
Un webhook es una solicitud HTTP que Didit envía a tu URL cuando algo cambia. Añade un destino en Desarrolladores → Webhooks, suscríbete a los eventos que quieras (no hay comodín, lista todos), guarda el secreto de firma, y verifica la firma antes de procesar nada.
Didit no te envía un correo cuando una sesión pasa a En revisión o Rechazada. Para enterarte en el momento en que un estado cambia, sin recargar la consola, configura un webhook: una URL en tu servidor a la que Didit envía la actualización automáticamente.
Los webhooks son el patrón de integración recomendado. Sondear el endpoint de decisión funciona como respaldo, pero es más lento, consume más solicitudes, y se pierde eventos que solo se entregan por webhook: ediciones de datos hechas por un revisor, cambios de estado de transacciones y cambios a nivel de entidad.
#Configurar uno
- Ve a Desarrolladores → Webhooks
Abre Desarrolladores → Webhooks en la aplicación y el entorno correctos.
- Añade un destino
Pulsa Añadir endpoint, introduce una URL HTTPS pública, elige los eventos y la versión v3, y guarda. No hay comodín: suscribe cada evento.
- Guarda el secreto de firma
Abre el endpoint y revela el secreto tras volver a autenticarte. Se oculta después de 60 segundos. Guárdalo en tu servidor y verifica la firma del cuerpo sin modificar antes de procesarlo.
- Pruébalo
Pulsa Enviar evento de prueba y selecciona un escenario. El envío está firmado; comprueba la solicitud, la respuesta y su estado en el inspector o tu servidor.
#Los eventos a los que puedes suscribirte
No hay comodín: lista cada familia de eventos que quieras. Repartirlos entre varios destinos está bien y a menudo es más limpio.
| Evento | Se dispara cuando |
|---|---|
status.updated | El estado de una sesión de KYC o KYB cambia. El que casi con toda seguridad quieres |
data.updated | Se edita un dato de verificación después de crearse: un revisor corrigiendo un campo |
user.status.updated | Un usuario consolidado pasa entre ACTIVE, FLAGGED y BLOCKED |
user.data.updated | Cambian el perfil, los contadores o los identificadores de un usuario consolidado |
business.status.updated | Cambia el estado de una empresa consolidada |
business.data.updated | Cambian los datos de una empresa consolidada |
transaction.created | Se crea una transacción y su veredicto inicial está listo |
transaction.status.updated | El estado de una transacción cambia después |
travel_rule.status.updated | Cambia el estado de un intercambio de Travel Rule |
No existe session.status.updated ni kyc.completed. Si te suscribiste a un
nombre que no está en esta lista, no recibirás nada, y parecerá exactamente un
fallo de entrega. Comprueba primero el nombre.
#Qué debe hacer tu endpoint
- Verificar la firma antes que nada. Aplica HMAC al cuerpo en bruto de la solicitud, nunca a una versión re-serializada del JSON analizado, porque volver a convertirlo a cadena cambia los bytes y la firma no coincidirá. Usa una comparación en tiempo constante.
- Devolver un 2xx rápido. Haz el trabajo pesado de forma asíncrona, después de responder.
- Ser idempotente. Usa como clave el id del evento, o el id de sesión más el estado más el tipo de webhook. Los reintentos y los duplicados ocurren.
- Gestionar cada estado que te importe, incluidos los que llegan mucho después del alta: una sesión aprobada puede pasar más tarde a En revisión a través de la monitorización AML continua.
- Solo HTTPS. Los endpoints HTTP simples no son compatibles.
#Reintentos
Didit reintenta las respuestas 5xx y 404 dos veces: aproximadamente 1 minuto después del fallo inicial y 4 minutos después del primer reintento. El tiempo de espera es de 5 segundos. Los fallos de conexión y los timeouts no activan estos reintentos automáticos. Consulta cada intento en el endpoint y usa Reenviar cuando corresponda. Reconcilia los resultados mediante el endpoint de decisión si falta una entrega.
Los webhooks no garantizan la entrega durante una caída prolongada. Recupera los estados que falten con el endpoint de decisión y procesa los eventos de forma idempotente.
#Detrás de un firewall o un WAF
Didit entrega desde la IP estática 18.203.201.92 con un user agent DiditWebhook/2.0. Si tu borde bloquea clientes desconocidos (la postura por defecto de Cloudflare, por ejemplo), permite esa IP para el hostname receptor, o las entregas fallarán antes de llegar a tu código.
#¿Todavía no tienes un backend?
Puedes seguir vigilando los resultados manualmente en la sección Verifications de la consola mientras construyes uno, o usar un enlace de verificación sin código mientras tanto.
#Próximos pasos
- Cuando un webhook no llega: cuando un webhook nunca llega
- Entiende qué significa cada estado una vez que llega: qué significa cada estado de sesión
- Referencia técnica completa, incluidos ejemplos de código de verificación de firma: Webhooks
¿Sigues atascado? Habla con una persona.
Incluye el ID de tu organización y el ID de la sesión sobre la que preguntas.