ID Analysis

El servicio de ID Analysis lee documentos de identidad a partir de una foto. Del frente extrae los campos impresos (la zona visual o VIZ), lee el MRZ y el código de barras si el documento los tiene, identifica el tipo de documento contra un catálogo de más de 90 templates de la región y recorta el rostro para que usted lo compare con una selfie. Del dorso extrae lo mismo y además responde la pregunta clave: ¿este dorso corresponde al documento del frente? El flujo es de una o dos llamadas, y el único estado que usted transporta es un identificador:

1.  POST /front   { info, image }                      →  200 { uuid, id, front: { viz… }, hasBackSide }
2.  POST /back    { info, image, relatedUuid: uuid }   →  200 { back: { …validaciones }, crossMatchConfidence }

front.hasBackSide le dice si el documento identificado tiene dorso que analizar. Si no lo tiene —un pasaporte, por ejemplo—, el flujo termina en el paso 1.

La regla de decisión

Esta es la parte más importante de la integración. Escríbala en positivo:

// FRENTE — aceptar exige las tres condiciones. Cualquier otra cosa NO acepta.
const frenteOk =
  status === 200 &&
  body.message === "Operation end successfully." &&
  body.id !== "unknown";

// DORSO — además de lo anterior:
const dorsoOk = body.back.frontBackTemplateValidation === true;
// y revisar body.crossMatchConfidence antes de dar por buenos los datos

El código 200 no significa «datos extraídos». Una foto sin documento legible también responde 200, con message: "Cant get document fields", id: "unknown" y viz vacío. Y un dorso que no corresponde al frente también responde 200 / "Operation end successfully." — lo que cambia es back.frontBackTemplateValidation: false. Quien decide solo sobre el código de estado acepta documentos ilegibles y documentos armados con caras de dos documentos distintos.

Los tres identificadores — no los confunda

Campo	Qué es
`uuid`	El identificador de la transacción. Es el `relatedUuid` del dorso, el dato que necesita soporte, y llega también en la cabecera `x-request-id`.
`id`	El tipo de documento identificado (p. ej. `VU-ARG-ID-04`), o `"unknown"`.
`info`	Su referencia (2–256 caracteres), devuelta tal cual.

Los cuerpos de error traen un uuid generado en el momento que no corresponde a ninguna transacción. Solo los 200 de /front devuelven un uuid utilizable como relatedUuid.

Endpoints

Método	Ruta	Para qué sirve
`POST`	`/front`	Analizar el frente. Devuelve el `uuid` que engancha con el dorso.
`POST`	`/back`	Analizar el dorso y cruzarlo con el frente (`relatedUuid` obligatorio).
`GET`	`/listTemplates`	Los identificadores de los documentos soportados.
`GET`	`/listTemplatesByCountry`	Lo mismo, agrupado por país.
`GET`	`/{templateId}/details`	Qué campos, MRZ, barcode y validaciones esperar de un template.
`GET`	`/{templateId}/images`	Imágenes de muestra anonimizadas del template.
`GET`	`/version`	Verificar conectividad. Evalúe el código de estado, no el cuerpo. No exige api-key.

La URL base depende del ambiente y se la entrega VU junto con su api-key. En los ejemplos aparece como BASE_URL.

Autenticación

Cada llamada lleva la cabecera Api-Key con la clave de su ambiente.

curl -X GET "$BASE_URL/version" \
  -H "Api-Key: $VU_ID_ANALYSIS_API_KEY"

La api-key vive en su backend. Nunca la incruste en una app móvil ni en el front-end: cualquiera puede extraerla del binario o del bundle.

Un ejemplo completo

curl -X POST "$BASE_URL/front" \
  -H "Api-Key: $VU_ID_ANALYSIS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "info": "onboarding-12345",
    "image": "/9j/4AAQSkZJRgABAQ..."
  }'

Un frente leído se ve así, recortado a los campos que importan:

{
  "uuid": "e2084653-7268-4748-9b80-a0da6a22a875",
  "info": "onboarding-12345",
  "id": "VU-ARG-ID-04",
  "ocrType": "template",
  "front": {
    "hasBackSide": true,
    "viz": {
      "names": "NIHAD ELIDUVINA",
      "surname": "CELDA",
      "number": "11433784",
      "dateOfBirth": { "day": 2, "month": 3, "year": 1951 }
    },
    "face": { "expected": true, "detected": true, "image": "/9j/4AAQ..." }
  },
  "code": 200,
  "message": "Operation end successfully.",
  "benchmark": 2780
}

Las tres condiciones se cumplen ⇒ documento leído. Guarde el uuid, use front.viz, y como hasBackSide es true, continúe con /back. El recorte de front.face.image está listo para compararse contra la selfie con Face Analysis.

Ambientes

Homologación puede ir adelantada respecto de producción. UAT también valida versiones preproductivas, así que puede diferir en tiempos de respuesta y en detalles del resultado. Úselo para certificar su integración —el contrato, los códigos, el manejo de errores—, no como referencia de performance.

Continuar

Integración

El flujo frente → dorso, los requisitos de imagen, el catálogo de templates y la checklist de producción.

Respuestas

La estructura de front y back, las validaciones cruzadas y los dos 200 que no aprueban.

Errores

Códigos, el 422 que devuelve su request completo y cuáles errores se reintentan.

Empezar aquí

Face Analysis

Antispoofing Facial

Connection Fingerprint

ID Analysis

La regla de decisión

Los tres identificadores — no los confunda

Endpoints

Autenticación

Un ejemplo completo

Ambientes

Continuar

Integración

Respuestas

Errores

​La regla de decisión

​Los tres identificadores — no los confunda

​Endpoints

​Autenticación

​Un ejemplo completo

​Ambientes

​Continuar

Integración

Respuestas

Errores

La regla de decisión

Los tres identificadores — no los confunda

Endpoints

Autenticación

Un ejemplo completo

Ambientes

Continuar