# Obtener resultados de verificación con webhooks

Source: https://help.didit.me/es/integration/webhooks-basics
Updated: 2026-10-12

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.

[Video: Resumen de webhooks - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI&t=192)

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

1. **Ve a Desarrolladores → Webhooks**

   Abre **Desarrolladores → Webhooks** en la aplicación y el entorno correctos.

2. **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.

3. **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.

4. **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.

![Destinos de webhook en la consola de Didit con eventos suscritos e historial de entregas](https://help.didit.me/screenshots/webhooks-light.webp)

*Cada destino tiene sus propios eventos suscritos, secreto de firma y registro de entregas.*

## 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 |

> **Note:** 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](https://help.didit.me/es/aml-screening/ongoing-monitoring).
- **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.

> **Warning:** 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](https://help.didit.me/es/integration/integration-options) mientras tanto.

## Próximos pasos

- Cuando un webhook no llega: [cuando un webhook nunca llega](https://help.didit.me/es/integration/webhook-troubleshooting)
- Entiende qué significa cada estado una vez que llega: [qué significa cada estado de sesión](https://help.didit.me/es/verification-sessions/session-statuses)
- Referencia técnica completa, incluidos ejemplos de código de verificación de firma: [Webhooks](https://docs.didit.me/integration/webhooks)