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

# How to combine document and biometric modules

> Best practices for structuring customer journeys that combine document verification, liveness checks, and facematch modules.

This guide explains best practices for structuring customer journeys and handling JSON schemas when combining:

* Document modules
* Liveness module
* Facematch module

## Recommended module sequence

A typical customer journey flow for documents and biometrics involves sequencing modules in the following pattern:

```mermaid theme={null}
graph TD
    A[Document Verification] --> B[Liveness Verification]
    B --> C[Facematch Verification]
```

* **Document first**: Establishes the identity baseline for capturing and validating official documents, such as driver's licenses and passports. Document verification typically involves three main modules:

  * Document Classification
  * Document Authentication
  * Document Extraction

  To learn about the best practices for module sequencing, refer to the [Group documents modules](/docs/go-v1/guides/best-practices/ordering-document-module) guide.

* **Liveness second**: Ensures the person submitting the document is physically present and not using a static image. The **Liveness** module captures a live selfie or video to confirm the user’s presence.

* **Facematch last**: Confirms that the person in the live selfie matches the document photo. The **Facematch** module compares the live image with the document image to ensure they are from the same individual.

Another recommended sequence is **Liveness** → **Document** → **Facematch**. This approach captures proof of life first, then documents, and concludes with facial comparison.

Regardless of the sequence you choose, it's important that facematch comes after document verification to ensure proper identity confirmation.

<Note>
  These are recommended patterns only. You can sequence modules according to your specific use cases and business requirements.
</Note>

### JSON schema structure

This section examines the data schema created when documents and biometrics modules are combined in a customer journey. The schema applies once the journey is published on the GBG GO platform.

These schemas define the payload structure for the `/journey/start` endpoint in pre-fill mode. Document and biometric data is mapped to their respective properties within the `context` object. For example:

```json JSON theme={null}
{
  "resourceId": "your-journey-resourceId@latest",
  "context": {
    "subject": {
      "identity": {
        "firstName": "Sarah",
        "lastName": "Johnson",
        "dateOfBirth": "1990-05-15"
      },
      "documents": [
        {
          "side1Image": "Base64-encoded string or binary data",
          "side2Image": "Base64-encoded string or binary data"
        }
      ],
      "biometrics": [
        {
          "faceImage": "Base64-encoded string or binary data"
        }
      ]
    }
  }
}
```

<Info>
  In the `biometrics` schema, `faceImage` is the live selfie captured during the journey. When a document module is also included, the anchor (reference) image is automatically populated from the document image extracted by the **Document Extraction** module. You do not need to provide an anchor image yourself for this case. The system uses the extracted document image as the anchor for facematch comparisons. This simplifies the integration and ensures that the correct reference image is used for biometric verification.
</Info>

The fields you need to provide depend on which modules your journey uses:

* **Liveness only**: Pass `faceImage`.
* **Facematch only**: Pass `face1Image` (selfie) and `face2Image` (anchor).
* **Liveness + Facematch**: Pass `faceImage` (selfie) and `face2Image` (anchor).
* **Documents + Biometrics**: Pass `side1Image` and `side2Image` (if applicable) for document verification, along with `faceImage`. The anchor image is automatically sourced from the extracted document.

#### Document schema

This is the standard schema for the document modules:

```json JSON theme={null}
"documents": [
 {
   "side1Image": "Base64-encoded string or binary data",
   "side2Image": "Base64-encoded string or binary data"
 }
]
```

<Note>
  `side2Image` is only required for documents that have information on both sides (example: driver's licenses and national ID cards).
</Note>

#### Biometrics schema

The biometric field names depend on which modules are in the journey.

For **Liveness** alone, or **Documents + Biometrics**:

```json JSON theme={null}
"biometrics": [
  {
    "faceImage": "Base64-encoded string"
  }
]
```

For **Facematch** alone:

```json JSON theme={null}
"biometrics": [
  {
    "face1Image": "Base64-encoded string",
    "face2Image": "Base64-encoded string"
  }
]
```

For **Liveness + Facematch**:

```json JSON theme={null}
"biometrics": [
  {
    "faceImage": "Base64-encoded string",
    "face2Image": "Base64-encoded string"
  }
]
```

<Note>
  When a document module precedes **Facematch** in the journey, you only need to pass `faceImage`. The system automatically uses the document portrait extracted by the **Document Extraction** module as the anchor for the facematch comparison.
</Note>

## Supported file formats

GBG GO supports the following file formats for document and biometric image uploads:

* PNG
* JPEG
* BMP

<Warning>
  HEIC format is not supported for document and biometric image uploads. If you attempt to upload an HEIC file, the system returns an error.
</Warning>

## Key terminologies

* `faceImage`: The live selfie captured during the journey. Used by **Liveness** and **Facematch** when one image is required.
* `face1Image`: The selfie submitted to standalone **Facematch** for comparison against an anchor.
* `face2Image`: The anchor image **Facematch** compares the selfie against. Sourced from a document processed earlier or a trusted customer reference image.
* `side1Image`: Primary document image (usually the front side containing the photo).
* `side2Image`: Secondary document image (back side, if applicable).