Skip to main content

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.

Journey execution

This section outlines best practices for executing journeys in GBG GO.

Use specific journey versions

Always use specific journey versions instead of @latest.
JSON
// Not recommended
{
  "resourceId": "8c24f3a5b76d09e182c397fd45c91ae3f8b530d7a19e64c2bd93f5a76c48e09f@latest"
}

// Recommended
{
  "resourceId": "8c24f3a5b76d09e182c397fd45c91ae3f8b530d7a19e64c2bd93f5a76c48e09f@3x5wz848"
}

Why this is important

  • Slower journey execution: GO must connect to the journey builder to retrieve the latest version. This makes starting journeys with @latest slower than using specific versions. Note that the delay is small (<1 second).
  • Unpredictable behavior: After publishing changes in the journey builder, there could be some delay before those changes reflect, when using @latest. On the contrary, when using a specific journey version, published changes are available right away.
The timing of this changeover isn’t predictable or easily observable.

Module dependencies

This section outlines best practices for managing module dependencies in GBG GO.

Configure NameMatch module dependencies

When using the NameMatch module, ensure DocumentExtraction module is added to the journey as a dependency. The NameMatch module requires extracted document data to function properly. Without DocumentExtraction:
  • NameMatch verification may fail.
  • Users may experience incomplete verification flows.

Implementation best practice

  • Add DocumentExtraction module before the NameMatch module in your journey.
Check the guide Best practices for ordering document modules in GBG GO to learn more about module ordering and dependencies.

Document and biometric modules

This section outlines best practices for structuring customer journeys that combine document verification with biometric modules.

Module sequencing

Most use cases for sequencing document and biometric modules follow this pattern:
  • Document first: Establishes the identity baseline by capturing and validating official documents (example; driver’s license, passport).
  • Liveness second: Ensures the person submitting the document is physically present and not using a static image.
  • Facematch last: Confirms that the person in the live selfie matches the document photo.

Key schema considerations

When combining document and biometric modules, the JSON schema structure for the context object include:
  • Identity details: First name, last name, date of birth.
  • Documents: An array of document objects. Contains fields for side1Image and side2Image.
  • Biometrics: An array of biometric objects. The biometric fields you provide depend on which modules your journey uses:
    • Liveness only: Pass faceImage.
    • Facematch only: Pass face1Image and face2Image.
    • Liveness + Facematch: Pass faceImage and face2Image.
    • Documents + Biometrics: Pass faceImage (the face2Image anchor is automatically populated from the document image extracted by the Document Extraction module).
For more details on document and biometrics best practices, see the complete Document and biometrics guide.