Skip to main content

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:

Estructura del Payload de Evento

Todos los webhooks KYC comparten el mismo sobre exterior. El objeto payload 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.
Si está presente, payload.entity incluye todas las columnas de la entidad (JSON seguro, fechas en ISO).

Campos comunes del sobre (envelope)

string
El tipo de evento (ej., kyc.validation_approved)
string
Timestamp ISO 8601 cuando ocurrió el evento
string
Su ID de organización
string
ID de la validación KYC en Gu1 (clave primaria del registro)
string
El ID de entidad (persona) siendo verificada
object
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).
string
Estado actual de validación: pending, in_progress, in_review, approved, rejected, abandoned, expired, cancelled

Objeto 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):
Ejemplo rechazado (completo):

Payloads Específicos de Eventos

kyc.validation_created

Enviado cuando se crea una nueva validación KYC. El payload es el registro de validación; entity no se incluye (evento no terminal).
Caso de uso: Envíe la URL de validación a su cliente por correo electrónico o SMS.

kyc.validation_in_progress

Enviado cuando un cliente inicia el proceso de verificación. entity no se incluye.
Caso de uso: Actualice la UI para mostrar estado “Verificación en progreso”.

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.
Caso de uso: Notifique al equipo de compliance para revisión manual. Actualice la UI para mostrar “En revisión por equipo de compliance”.

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).
Campos Adicionales:
  • 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ón
  • extractedData: Información personal extraída del documento
  • verifiedFields: Array de campos que se verificaron con éxito
  • warnings: Array de advertencias detectadas durante la verificación (vacío si fue aprobado)
  • decision: Resultados de verificación para cada verificación
Caso de uso: Active la cuenta del cliente y otorgue acceso a servicios.

kyc.validation_rejected

Enviado cuando falla la verificación. entity se incluye (estado actual de la entidad en Gu1).
Campos Adicionales:
  • entity: Registro completo de la entidad en Gu1 al momento del envío
  • warnings: Array de razones por las que falló la verificación
  • rejectionReason: Razón principal del rechazo
Caso de uso: Notifique al cliente que la verificación falló y proporcione orientación sobre los próximos pasos.

kyc.validation_abandoned

Enviado cuando un cliente inicia pero no completa la verificación. entity no se incluye.
Campos Adicionales:
  • lastStep: El último paso que el cliente completó antes de abandonar
Caso de uso: Envíe un correo de recordatorio para completar la verificación.

kyc.validation_expired

Enviado cuando una sesión de validación expira sin completarse. entity no se incluye.
Caso de uso: Limpie validaciones pendientes y notifique al cliente para reiniciar la verificación.

kyc.validation_cancelled

Enviado cuando una validación es cancelada manualmente por la organización. entity no se incluye.
Caso de uso: Notifique al cliente que la validación fue cancelada. Limpie recursos asociados y actualice el estado en su sistema.

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

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 el validationId de Gu1 en su base de datos. Esto le permite consultar detalles de validación más tarde si es necesario.
Podría recibir el mismo webhook múltiples veces. Use el validationId para asegurar que procese cada evento solo una vez.
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.
Siempre verifique el header X-Webhook-Signature para asegurar que el webhook sea auténtico. Vea la guía de seguridad para detalles.
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

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
extractedData y verifiedFields solo se incluyen en:
  • kyc.validation_approved
  • kyc.validation_rejected
No están presentes en otros tipos de eventos como validation_created o validation_in_progress.
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)
Vea Seguridad de webhooks — en especial Cuerpo sin procesar vs JSON analizado, Historial en el dashboard y Fallos intermitentes de firma.
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