Skip to main content
Una Verification representa el ciclo completo de verificación de un usuario. Desde que se crea el Link hasta que el usuario finaliza o abandona el proceso, la Verification atraviesa diferentes estados y pasos. Cuando concluye, puedes consultar los datos extraídos del documento, la geolocalización y el resultado de la prueba de vida.

Ciclo de vida de una Verification

La Verification avanza por estados y pasos que reflejan el progreso del usuario en el flujo.

Estados posibles

Pasos del flujo

Obtener detalles completos de una Verification

Usa GET /verifications/{id} para recuperar todos los datos extraídos, geolocalización y metadatos.

Respuesta de ejemplo

El identificador de la verificación viaja en _id. Los datos documentales extraídos por OCR viven dentro del objeto data, no en la raíz de la respuesta.

Polling ligero de estado

GET /verifications/{id}/status es un endpoint público: no lleva token Bearer. En su lugar exige el query param linkId, que demuestra que quien consulta es el usuario final previsto y no alguien que adivinó el verificationId.

Respuesta básica

Incluir operationGuid y method

Agrega include=operationGuid para recibir un objeto con más contexto. Requiere linkId igualmente.
Omitir linkId, o enviar uno que no corresponde a esta verificación, devuelve 403. Este parámetro pasó a ser obligatorio en la versión 2.2.0.

Listar verificaciones

Últimas 100 verificaciones

La respuesta es un objeto paginado:

Verificaciones de la última hora

Paginación

Donde 20 es el tamaño de página (máximo 100) y 1 es el número de página.

Verificaciones relacionadas del mismo cliente

GET /verifications/{id}/related devuelve todas las demás verificaciones del mismo cliente, es decir, de la misma compañía y con el mismo externalUserId en su Link, ordenadas de la más reciente a la más antigua.
La lista está vacía cuando el Link de la verificación consultada no tiene externalUserId, porque no hay identificador con el que agrupar.

Imágenes asociadas

Listar imágenes de una verificación

Obtener una imagen por ID

Los identificadores están en el objeto images de la verificación: addFront, addBack y el array register con los frames de la selfie.

Endpoints públicos del flujo

Los tres endpoints siguientes los invoca el dispositivo del usuario durante el flujo, sin token. Todos exigen que la verificación siga asociada a un Link activo y esté en estado pending o started.

Reportar geolocalización

Todos los campos de ubicación viajan anidados dentro del objeto geolocation.
tier, policy, ipDistanceKm y serverIp no son propiedades aceptadas: se derivan en el servidor y la petición se rechaza con 400 si el cliente envía cualquiera de ellas.
Otras dos validaciones devuelven 400:
  • Declarar un source de dispositivo (gps, wifi o cell) sin deviceLatitude y deviceLongitude.
  • Un capturedAt que se aparte más de 24 horas del reloj del servidor.

Reportar errores

Identificar a un usuario en curso

PATCH /verifications/identify cubre el caso de un Link adaptativo creado sin externalUserId. Rellena el externalUserId del Link a partir del email indicado y vuelve a resolver la rama adaptativa.
Reglas de este endpoint:
  • Repetir el mismo email siempre es una operación sin efecto y responde 200.
  • Un identificador que la API fijó al crear el Link no se puede sobrescribir: un email distinto responde 409 con identifierAlreadyBound.
  • Un identificador que fijó este mismo endpoint (es decir, tecleado por la persona) sí es corregible: un email distinto se acepta y la rama se vuelve a resolver.
  • Un email inválido o ausente responde 400.

Retroalimentación manual

Si necesitas anular o corregir el resultado de una verificación, usa POST /verifications/feedback.

Razones de feedback disponibles

Cada razón devuelve _id y reason. Usa ese _id como reasonId al enviar el feedback.

Referencia del objeto geolocation

geolocation combina una posición reportada con una medida de cuánto confiar en ella. No aparece hasta que se ha reportado una ubicación, y tier siempre acompaña a las coordenadas: nunca hay una latitud y longitud sueltas.
policy, ipDistanceKm y serverIp se devuelven únicamente en los GET autenticados. No aparecen en las respuestas del PATCH público ni en los webhooks. Devolver estas señales antifraude a un llamador no autenticado le permitiría calibrar una ubicación falsificada contra el control diseñado para detectarla.
source es un valor inferido, no medido: la Geolocation API del W3C no expone su proveedor, así que gps, wifi y cell se deducen en el cliente a partir de bandas de altitud, velocidad y precisión. Solo ip y none son certeros. Al ser declarado por el cliente, todo el conjunto es falsificable: el ipDistanceKm calculado en el servidor es el contraste.
Para aplicaciones en tiempo real, combina webhooks con polling ligero de GET /verifications/{id}/status. Los webhooks te notifican del cambio, y el polling te permite confirmar el estado si el webhook se demora.
Última modificación el 28 de agosto de 2026