Leer la respuesta

La decisión ya la tomó con status, message, id y frontBackTemplateValidation. Esta página explica el resto: qué trae cada bloque, cómo leer las validaciones cruzadas y qué particularidades del contrato rompen deserializadores estrictos.

Campos de primer nivel

Campo	Tipo	Para qué sirve
`uuid`	string	El identificador de la transacción. Es el `relatedUuid` del dorso. Registrelo siempre.
`info`	string	Eco de su referencia.
`date` / `time`	string	Momento de recepción (UTC).
`id`	string	El template identificado (`VU-ARG-ID-04`) o `"unknown"`. Parte de la decisión.
`ocrType`	string	Cómo se extrajo `viz`, en orden de confiabilidad: `template` > `templateLess` / `templateLessFallBack` > `mrzBruteForce` / `barcodeBruteForce` (la VIZ replica en gran parte el MRZ/barcode).
`isNativePersonDocument`	bool \| null	¿La nacionalidad del titular coincide con el país emisor? `false` = extranjero documentado. `null` = no se pudo determinar — nunca lo trate como `false`.
`crossMatchConfidence`	object	Consistencia entre fuentes — ver abajo.
`front` / `back`	object	El resultado por cara. En `/back`, `front` es el frente reproducido de la transacción original.
`code` / `message`	number / string	Espejo del código HTTP y su versión legible.
`benchmark`	number	Milisegundos de proceso del servicio. No incluye red.

Dentro de `front` y `back`

Campo	Descripción
`viz`	Los campos impresos extraídos. El conjunto de claves varía por template (consulte `GET /{templateId}/details`); las fechas son objetos `{day, month, year}`; un campo no leído puede llegar como cadena vacía.
`mrz`	`expected` es tri-estado: `true`/`false` con template conocido, `null` cuando no. Con lectura exitosa agrega `result` (campos parseados), `extras` (dígitos verificadores — ojo: los valores son cadenas, `"100"`, `"True"`) y `raw` (las líneas del MRZ).
`barcode`	`expected / readable / detected`. Con lectura exitosa: `result` — un arreglo de exactamente un objeto — y `raw`. Un barcode esperado con `detected: false` no es un error: la captura no permitió leerlo.
`face`	`expected`, `detected`, `box` e `image`: el recorte del rostro en base64 JPEG, listo para comparar contra una selfie con Face Analysis.
`image`	La foto del documento normalizada (recortada y alineada), en base64. Siempre presente y pesada (cientos de KB).
`quality` / `rawOcr`	Métricas de la captura y el OCR crudo agrupado por renglón. Diagnóstico.
`security`	Solo con `antiSpoofingDocument`: `notSpoofingConfidence` (0–100) e `isSpoofing`. Ver la advertencia de abajo.
`hasBackSide`	Solo en `front` con template identificado: si el documento tiene dorso para analizar.

Las validaciones del dorso

Campo	Descripción
`frontBackTemplateValidation`	La validación decisiva: `true` si el dorso corresponde al tipo de documento del frente.
`frontBackDataValidation`	Puntaje 0–100 del cruce de datos entre caras, o `-1` = no hubo datos comparables (no es un error). `frontBackDataValidationStrategy` indica la estrategia (`"None"` cuando no se comparó).
`backIsTheSameIdTypeThatFront`	Campo legado con valores centinela: `1` = el dorso no corresponde, `99` = corresponde pero sin datos comparables, otro valor = puntaje. Prefiera los dos campos anteriores.

Los dos `200` que no aprueban

Foto sin documento legible

{
  "uuid": "b89bff81-00ba-435b-8c37-60142f273f88",
  "id": "unknown",
  "ocrType": "templateLess",
  "events": ["..."],
  "front": { "viz": {}, "mrz": { "expected": null, "detected": false } },
  "code": 200,
  "message": "Cant get document fields"
}

Trátelo como documento ilegible y pida otra captura. Note tres particularidades de esta variante: message cambia, mrz.expected es null (template desconocido), y el arreglo events llega aunque no se haya pedido.

Dorso de otro documento

{
  "uuid": "4312af20-876c-402d-a60a-5fbfb2fd9de8",
  "id": "VU-ARG-ID-04",
  "back": {
    "mrz": { "expected": true, "detected": false },
    "frontBackTemplateValidation": false,
    "frontBackDataValidation": -1,
    "backIsTheSameIdTypeThatFront": 1
  },
  "code": 200,
  "message": "Operation end successfully."
}

Esta es la trampa más cara de esta API. Un documento armado con el frente de una persona y el dorso de otra pasa cualquier control que decida sobre el código HTTP o el message —acá los dos dicen «éxito»—. La detección está solo en back.frontBackTemplateValidation (y su eco legado backIsTheSameIdTypeThatFront: 1). Prográmelo como condición obligatoria y pruébelo antes de salir. Los campos leídos del dorso ajeno son basura coherente: el OCR leyó algo del documento equivocado, por eso el análisis «funcionó».

`crossMatchConfidence`: la consistencia entre fuentes

Hasta tres bloques —mrzVersusViz, barcodeVersusViz, barcodeVersusMrz—, cada uno con porcentajes de similitud 0–100 por campo; las fechas se desglosan en día/mes/año.

"crossMatchConfidence": {
  "mrzVersusViz": {
    "number": 88.9,
    "dateOfBirth": { "day": 100.0, "month": 100.0, "year": 100.0 },
    "nationality": 100.0,
    "names": 100.0,
    "surname": 100.0
  }
}

En el ejemplo, el MRZ coincide al 100 % con la VIZ salvo un dígito del número de trámite (88.9 — un carácter dudoso del OCR).

El servicio no impone umbral: la política de aceptación es suya. Decida por campo según qué datos alimentan su proceso. Y en un /front sin nada que cruzar, crossMatchConfidence llega como {} — es normal, no un error.

El antispoofing es informativo

Con antiSpoofingDocument: true la respuesta agrega security; con antiSpoofingFaceInDocument: true, face.notSpoofingConfidence y face.isSpoofing:

"front": {
  "security": { "notSpoofingConfidence": 94.69, "isSpoofing": false },
  "face": { "notSpoofingConfidence": 99, "isSpoofing": false }
}

Un isSpoofing: true no cambia el código de la respuesta — llega igualmente con 200 / "Operation end successfully.". El servicio no rechaza por usted: su código debe leer estos campos y aplicar su política. Y si el análisis falló, security llega vacío ({}): la ausencia de isSpoofing significa «no evaluado», nunca «no es fraude».

Particularidades que rompen deserializadores

mrz.expected es tri-estado (true | false | null). Tipe como opcional/nullable.
mrz.extras trae números y booleanos como cadenas ("100", "True"). No los parsee como number/bool sin conversión.
barcode.result es un arreglo de un elemento, igual que front/back en GET /{templateId}/images.
isNativePersonDocument es tri-estado. null = indeterminado.
Las claves de viz varían por template y pueden faltar o llegar vacías. No asuma un esquema fijo: use /{templateId}/details como contrato por documento.
No dependa del orden de las claves JSON — varía entre las dos variantes de 200.

Errores

Códigos de error, el 422 que devuelve su solicitud completa y cuáles se reintentan.

Empezar aquí

ID Analysis

Face Analysis

Antispoofing Facial

Connection Fingerprint

Campos de primer nivel

Dentro de `front` y `back`

Las validaciones del dorso

Los dos `200` que no aprueban

Foto sin documento legible

Dorso de otro documento

`crossMatchConfidence`: la consistencia entre fuentes

El antispoofing es informativo

Particularidades que rompen deserializadores

Errores

​Campos de primer nivel

​Dentro de front y back

​Las validaciones del dorso

​Los dos 200 que no aprueban

​Foto sin documento legible

​Dorso de otro documento

​crossMatchConfidence: la consistencia entre fuentes

​El antispoofing es informativo

​Particularidades que rompen deserializadores

Errores

Campos de primer nivel

Dentro de `front` y `back`

Las validaciones del dorso

Los dos `200` que no aprueban

Foto sin documento legible

Dorso de otro documento

`crossMatchConfidence`: la consistencia entre fuentes

El antispoofing es informativo

Particularidades que rompen deserializadores