Descripción General
Los eventos de webhook KYC le permiten recibir notificaciones en tiempo real cuando cambia el estado de una verificación KYC. Gu1 envía automáticamente solicitudes HTTP POST a su endpoint de webhook configurado cada vez que se actualiza un estado de validación, permitiéndole automatizar flujos de trabajo de incorporación de clientes y mantener el cumplimiento.¿Por Qué Usar Webhooks KYC?
Actualizaciones en Tiempo Real
Reciba notificaciones instantáneas cuando cambie el estado de verificación
Eficiente
No es necesario consultar la API repetidamente
Flujos de Trabajo Automatizados
Actualice automáticamente cuentas de usuario según resultados de verificación
Mejor UX
Notifique a los clientes inmediatamente después de la verificación
Eventos Disponibles
Gu1 envía webhooks para los siguientes eventos de validación KYC:| Tipo de Evento | Descripción | Cuándo se Activa |
|---|---|---|
kyc.validation_created | Sesión de validación creada | Cuando crea una nueva validación KYC |
kyc.validation_in_progress | Cliente comenzó verificación | El cliente está completando activamente la verificación (llenando formulario) |
kyc.validation_in_review | Verificación en revisión | Verificación completada, requiere revisión manual del equipo de compliance |
kyc.validation_approved | Verificación aprobada | Identidad verificada con éxito |
kyc.validation_rejected | Verificación rechazada | Falló la verificación de identidad |
kyc.validation_abandoned | Cliente abandonó proceso | El cliente se fue sin completar |
kyc.validation_expired | Sesión de validación expiró | Sesión expirada (típicamente después de 7 días) |
kyc.validation_cancelled | Validación cancelada | Validación cancelada manualmente por la organización |
Estructura del Payload de Evento
Todos los webhooks KYC comparten el mismo sobre exterior. El objetopayload es el registro de validación KYC tal como está en Gu1 (mismos nombres de campo que en base de datos/API: id es el UUID de la validación, más entityId, organizationId, status, decision, extractedData, verifiedFields, warnings, metadata, marcas de tiempo, etc.).
El campo
entity (fila completa de la entidad en Gu1) solo se envía en resultados finales: kyc.validation_approved y kyc.validation_rejected. No se incluye en created, in_progress, in_review, abandoned, expired ni cancelled. Es un campo adicional: el resto del payload no cambia. En kyc.validation_approved, el auto‑relleno opcional de persona desde KYC sigue ejecutándose después del webhook (mismo orden que antes); payload.entity es una instantánea en el momento del envío (antes de ese paso). Para el estado tras el auto‑relleno, consultá la API de entidades.payload.entity incluye todas las columnas de la entidad (JSON seguro, fechas en ISO).
Campos comunes del sobre (envelope)
El tipo de evento (ej.,
kyc.validation_approved)Timestamp ISO 8601 cuando ocurrió el evento
Su ID de organización
ID de la validación KYC en Gu1 (clave primaria del registro)
El ID de entidad (persona) siendo verificada
Solo en
kyc.validation_approved y kyc.validation_rejected. Instantánea de la fila de entidad en Gu1 en el momento del envío (en aprobación, antes del auto‑relleno opcional).Estado actual de validación:
pending, in_progress, in_review, approved, rejected, abandoned, expired, cancelledObjeto decision (payload.decision)
Cuando una validación llega a un estado terminal o in_review con resultados del proveedor, payload.decision contiene el resultado completo del flujo KYC. Gu1 siempre persiste y devuelve ambas formas por cada feature: objeto singular (legacy) y array de un elemento (actual). Podés leer id_verification o id_verifications[0]; se mantienen sincronizados. Lo mismo aplica a liveness / liveness_checks, face_match / face_matches, aml_screening / aml_screenings e ip_analysis / ip_analyses.
Los campos de media (front_image, reference_image, images.*, etc.) son claves de almacenamiento Gu1 (kyc/...) tras el ingest. Obtenelas vía la API de media de validación. Filas antiguas pueden tener URLs HTTPS de corta duración hasta sincronizar.
Ejemplo aprobado (completo):
Payloads Específicos de Eventos
kyc.validation_created
Enviado cuando se crea una nueva validación KYC. Elpayload es el registro de validación; entity no se incluye (evento no terminal).
kyc.validation_in_progress
Enviado cuando un cliente inicia el proceso de verificación.entity no se incluye.
kyc.validation_in_review
Enviado cuando un cliente completa la verificación y requiere revisión manual del equipo de compliance.entity no se incluye.
kyc.validation_approved
Enviado cuando la verificación se completa con éxito.entity se incluye (fila completa en el momento del envío; el auto‑relleno opcional puede ejecutarse después, igual que antes).
entity: Registro completo de la entidad en Gu1 al momento del envío (todas las columnas; fechas en ISO)verifiedAt: Timestamp cuando se aprobó la verificaciónextractedData: Información personal extraída del documentoverifiedFields: Array de campos que se verificaron con éxitowarnings: Array de advertencias detectadas durante la verificación (vacío si fue aprobado)decision: Resultados de verificación para cada verificación
kyc.validation_rejected
Enviado cuando falla la verificación.entity se incluye (estado actual de la entidad en Gu1).
entity: Registro completo de la entidad en Gu1 al momento del envíowarnings: Array de razones por las que falló la verificaciónrejectionReason: Razón principal del rechazo
kyc.validation_abandoned
Enviado cuando un cliente inicia pero no completa la verificación.entity no se incluye.
lastStep: El último paso que el cliente completó antes de abandonar
kyc.validation_expired
Enviado cuando una sesión de validación expira sin completarse.entity no se incluye.
kyc.validation_cancelled
Enviado cuando una validación es cancelada manualmente por la organización.entity no se incluye.
Ejemplos de Código
Node.js - Manejo de Eventos KYC
Python - Manejo de Eventos KYC
Casos de Uso
Caso de Uso 1: Activación Automática de Cuenta
Active automáticamente cuentas de clientes cuando se aprueba el KYC:Caso de Uso 2: Monitoreo de Cumplimiento
Rastree rechazos de KYC para revisión de cumplimiento:Caso de Uso 3: Recuperación de Verificación Abandonada
Envíe recordatorios a clientes que abandonan la verificación:Mejores Prácticas
Use entity.externalId para Búsqueda
Use entity.externalId para Búsqueda
El webhook incluye
entity.externalId que es el ID que proporcionó al crear la entidad. Úselo para buscar al cliente en su base de datos.Almacene IDs de Validación
Almacene IDs de Validación
Almacene el
validationId de Gu1 en su base de datos. Esto le permite consultar detalles de validación más tarde si es necesario.Maneje Idempotencia
Maneje Idempotencia
Podría recibir el mismo webhook múltiples veces. Use el
validationId para asegurar que procese cada evento solo una vez.Devuelva 200 Rápidamente
Devuelva 200 Rápidamente
Siempre devuelva un código de estado 200 lo más rápido posible para confirmar recepción. Procese el webhook asincrónicamente si es necesario.
Verifique Firmas
Verifique Firmas
Siempre verifique el header
X-Webhook-Signature para asegurar que el webhook sea auténtico. Vea la guía de seguridad para detalles.Maneje Errores con Gracia
Maneje Errores con Gracia
Si el procesamiento falla, registre el error pero aún devuelva 200 para evitar reintentos. Almacene webhooks fallidos para revisión manual.
Solución de Problemas
No Recibo Webhooks
No Recibo Webhooks
Verificar estos elementos:
- La URL del webhook es públicamente accesible vía HTTPS
- El webhook está configurado y habilitado en el dashboard
- Suscrito a tipos de eventos KYC correctos
- El endpoint devuelve código de estado 200 dentro de 30 segundos
- Verificar logs del servidor para solicitudes entrantes
Falta extractedData
Falta extractedData
extractedData y verifiedFields solo se incluyen en:kyc.validation_approvedkyc.validation_rejected
validation_created o validation_in_progress.Falla la Verificación de Firma
Falla la Verificación de Firma
Causas comunes:
- Usar secreto incorrecto (verificar dashboard para secreto actual)
- Verificar firma en JSON analizado en lugar de cuerpo raw
- Re-verificar desde el JSON del monitor de webhooks (pretty-print /
JSON.stringify≠ bytes firmados) - Middleware que muta el body antes de verificar (algunos payloads fallan, otros pasan)
- Secreto no guardado correctamente después de creación del webhook
- Problemas de codificación (asegurar UTF-8)
Recibo Webhooks Duplicados
Recibo Webhooks Duplicados
Este es un comportamiento normal. Los webhooks pueden enviarse múltiples veces debido a problemas de red, tiempos de espera o reintentos.Siempre implemente idempotencia usando el
validationId del webhook y tipo de event.Próximos Pasos
Eventos de Entidades
Maneje eventos del ciclo de vida de entidades
Eventos de Reglas
Procese activaciones de reglas de cumplimiento
Seguridad de Webhooks
Asegure sus endpoints de webhook
Configuración
Configure ajustes de webhook