> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vu-one.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Interpreting responses

> How to read an ID Analysis response: the extracted fields, the front–back validations, crossMatchConfidence, and the two 200s that do not approve anything.

## The first-level fields

| Field | What it is |
| - | - |
| `uuid` | The transaction identifier. Log it always; it links `/back` and support tickets. |
| `info` | Your reference, echoed back verbatim. |
| `message` | The global result. Only `"Operation end successfully."` counts as a successful read. |
| `id` | The identified document type (e.g. `VU-ARG-ID-04`), or `"unknown"`. |
| `front` / `back` | The per-side result: extraction, cropped face, validations. |
| `crossMatchConfidence` | Consistency between data sources (MRZ vs VIZ vs barcode), 0–100 per field. |
| `events` | The internal pipeline trace, if you asked for it — or **unsolicited**, when the read failed. |

## Inside `front` and `back`

| Field | What it carries |
| - | - |
| `ocrType` | How the side was read: `template` (a known template drove the extraction) or generic OCR. |
| `viz` | The visual-zone fields. **Which fields appear is template-driven** — `GET /{templateId}/details` is authoritative. Empty (`{}`) when nothing was read. |
| `mrz` | The machine-readable zone (back): parsed fields, the raw lines, and per-field checksums. |
| `barcode` | The barcode content. `result` is a **1-element array**. |
| `face` | The portrait cropped from the document, in base64 — the input for [Face Analysis](/en/vucs/face-analysis/introduction). |
| `hasBackSide` | Whether this template expects a back side. |

## The back's validations

| Field | Meaning |
| - | - |
| `frontBackTemplateValidation` | `true` = the back belongs to the same document type as the front. **Part of the decision rule.** |
| `backIsTheSameIdTypeThatFront` | The legacy equivalent: `1` = mismatch, `99` = same type but no comparable data. |
| `frontBackDataValidation` | Data-level comparison between sides. `-1` = not computed. |

<Warning>
  **The most expensive trap: a mismatched back is not an HTTP error.** Front of one document + back of another = `200 / "Operation end successfully."` — the OCR *did* work, on both images; that is why the analysis “succeeded”. The detection lives in `back.frontBackTemplateValidation: false` (with `backIsTheSameIdTypeThatFront: 1`). A system that decides on the status code accepts documents assembled from two different IDs.
</Warning>

```json theme={null}
{
  "uuid": "4312af20-89ab-42a1-92a1-7bc0fe12de60",
  "message": "Operation end successfully.",
  "id": "VU-ARG-ID-04",
  "back": {
    "frontBackTemplateValidation": false,
    "backIsTheSameIdTypeThatFront": 1
  }
}
```

## The other 200 that approves nothing

A photo with no readable document returns `200` with `message: "Cant get document fields"`, `id: "unknown"`, an empty `viz` — and an **unsolicited** `events` block with the pipeline trace:

```json theme={null}
{
  "uuid": "b89bff81-53ba-4c8f-b02e-0e81f0722cbd",
  "message": "Cant get document fields",
  "id": "unknown",
  "front": { "viz": {} }
}
```

Treat it as “ask the user for another capture”, never as an approval with empty fields.

## `crossMatchConfidence`

Consistency between data sources, as 0–100 percentages per field:

```json theme={null}
{
  "crossMatchConfidence": {
    "mrzVersusViz": {
      "documentNumber": 88.9,
      "name": 100,
      "lastName": 100,
      "birthDate": 100
    }
  }
}
```

An `88.9` on one field usually means one doubtful OCR character. On the front alone, `crossMatchConfidence` is typically `{}` — there is only one source to compare; that is normal, not a failure.

<Note>
  **The service imposes no threshold.** The acceptance policy over `crossMatchConfidence` is yours: a strict onboarding may demand 100 on the document number and tolerate less on names.
</Note>

## Document antispoofing is informational

With `antiSpoofingDocument` / `antiSpoofingFaceInDocument`, the response adds `security.*` blocks (screen recapture, photocopy, tampering scores — e.g. `94.69`, `99`) and `face.isSpoofing`.

<Warning>
  These verdicts **do not change** the HTTP code or `message`: a document flagged as recaptured still returns `200 / "Operation end successfully."`. If your policy rejects on these signals, evaluate them explicitly. An empty `security` block (`{}`) means “not evaluated”, not “clean”.
</Warning>

## Deserializer particularities

1. `mrz.expected` is tri-state: `true` / `false` / absent.
2. The values inside `mrz.extras` are **strings**, even when they look numeric.
3. `barcode.result` is a 1-element array, not an object.
4. `isNativePersonDocument` is tri-state as well.
5. `viz` is template-driven: never hard-code the field set; read `GET /{templateId}/details`.
6. Responses weigh \~1 MB (embedded base64 images): size buffers accordingly and never log raw bodies.

<Card title="Next: Errors" icon="triangle-exclamation" href="/en/vucs/id-analysis/errors">
  Status codes, the 422 that echoes your whole request — image included — and which errors are safe to retry.
</Card>


## Related topics

- [Interpreting responses](/en/vucs/face-analysis/responses.md)
- [Reading the response](/en/vucs/antispoofing-face/responses.md)
- [Liveness Detection and Facial Biometrics in Identity Link](/en/identity-link/liveness.md)
- [Identity Link API Error Codes and Responses](/en/identity-link/errors.md)
- [Face Analysis](/en/vucs/face-analysis/introduction.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.