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.

The GBG GO v2 API uses an interaction-based model to execute identity verification journeys. Instead of retrieving tasks and schemas separately, you fetch interactions that describe what data is needed, collect it from the end user, and submit it, repeating this loop until the journey completes. The guides in this section walks you through the complete API-first integration flow for executing an interaction journey programmatically.

​
Before you begin

Make sure you have the following in place before using the API:
  • A published API journey. To learn how to create and publish a journey, refer to Create journeys. You need the journey’s resource ID and version to start a journey instance.
  • Your API credentials for API authentication. This includes Client ID, Client Secret, Username, and Password. These are provided by your GBG account manager.
  • Understanding of your journey’s interactions. Interaction journeys collect data through domain elements such as FullName, PrimaryDocument, or Selfie. Confirm which domain elements apply to your specific journey using the /fetch/interaction endpoint.

​
Execution flow

A complete interaction journey execution consists of the following steps:
  1. Authenticate: Get your access token to authorise API requests.
  2. Start a journey: Create a new journey instance using the published journey’s resource ID and version.
  3. Fetch the interaction: Retrieve the current interaction to discover what data the end user must provide.
  4. Submit interaction data: Send the collected domain element data to advance the journey.
  5. Fetch journey state: Poll the journey status to detect completion and retrieve verification results.

​
FAQ

These are the core building blocks of the GBG GO platform:
  • Journey: A journey is a structured workflow that guides an end user through verification steps such as identity checks, document processing, and fraud screening.
  • Module: A module is a functional component within a journey that performs a specific verification task. Examples include Document Classification, Document Authentication, Data Verification, Age Verification, and Facematch. Each module can have one or more variants, which are different configurations tailored to specific regions, compliance rules, or business requirements, for example, “US Data Verification.”
  • Capability: Capabilities are the underlying services that modules use to perform their tasks. For example, the Document Authentication module relies on the Document Authentication capability, which provides the core logic for verifying document authenticity.
  • Interaction: An interaction is a step in the journey where the platform collects information from the end user. When you fetch an interaction, the response describes which data elements are needed (the collects array), which are required or optional (the spec field), and which have already been provided (the outstanding array). In the v2 API, interactions replace the v1 task-based model.
  • Evaluation: An evaluation is a decision-making step in the journey where the platform determines an outcome, such as accept, reject, or refer for manual review, based on the results of the preceding verification modules.
A resource ID identifies a specific published version of a journey. When you publish a journey in GBG GO, the system assigns it a resource ID. You include this ID in the journey start request to tell the API which journey to run. To always use the most recently published version, append @latest to the resource ID (for example, your-resource-id@latest). To pin your integration to a specific version, use the fixed resource ID without @latest.An instance ID identifies a single execution of that journey. When you start a journey, the API creates a journey instance and returns a unique instanceId in the response. You use this instance ID in subsequent API calls.
In the v2 API, all journey execution is asynchronous. There is no synchronous mode.When you start a journey, the API returns an instanceId immediately. Backend modules such as document verification, face matching, data checks process in the background.To track progress, you poll the /journey/interaction/fetch endpoint to discover when the next interaction is available, or poll /journey/state/fetch to check the overall journey status.The recommended polling approach is to call the fetch endpoint at a base interval of 10 seconds, apply backoff on errors, and stop when the journey status changes from InProgress to either Completed or Failed.If you are migrating from v1: the async: true flag was a v1-specific concept. In v2, async behaviour is the default and does not need to be specified.

​
Next step

Go to Authenticate to get your access token.