Skip to main content
Understanding how the GBG GO platform works will help you create, manage, and integrate customer journeys. If you are a business user, you design workflows and configure verification steps. If you are a developer, you integrate with the API to start journeys, retrieve tasks, and submit customer data.

​
Customer journeys and workflow

A customer journey is a structured process that guides a user through steps such as identity verification, document processing, and approvals.
  • Business users create and configure customer journeys in the GBG GO platform. They define workflows, add verification steps, and publish journeys.
  • Developers integrate with the API to start journeys, retrieve tasks, and submit customer data.

​
Outcomes and decisions

In GBG GO, outcomes typically refer to module results while decisions refer to evaluation results. See Glossary of terms for more details. Outcomes and decisions are evaluated in order from top to bottom. When a condition is met, that result is returned and processing stops. For example, in a NameMatch module, if customer names match correctly, then the system returns the IsNameMatch outcome. In this case, the outcome has a configuration of Does name match = is true. All remaining configured outcomes or decisions are skipped.

​
Journey instance

When a journey starts, the system creates a journey instance, which represents an active execution of a customer journey. Each instance is assigned a unique instanceId, which you use to track progress, retrieve tasks, and submit data.

​
Prefill mode and non-prefill mode

When starting a journey using GO APIs, you can choose between two modes:
  • Prefill mode: lets you send customer data upfront when starting a journey. The system can auto-complete matching tasks based on the data provided.
  • Non-prefill mode: starts a journey without customer data. You send an empty context object, and customers provide required details through tasks later. This differs from prefill mode where you send data upfront.

​
Linear and adaptive journey processing

Journeys can be processed in two ways: linear or adaptive.
  • Linear processing: The journey follows a fixed sequence of steps. Each task must be completed in order before moving to the next.
  • Adaptive processing: The journey dynamically adjusts based on customer data and verification results. Tasks may be skipped or added depending on the context. Data is collected sequentially based on the journey stage, allowing for a more tailored verification process.

​
Resource ID and journey versions

A resource ID identifies a specific journey version. When a journey is published, it receives a unique resource ID. To start a journey, you provide this ID in the request. If you want to start the most recent published version, append @latest, for example, your-resource-id@latest. If your integration requires a specific version, use the fixed resource ID instead of @latest.

​
Tasks and data requirements

A task is an action a user must complete within a journey. These actions may involve providing identity details, uploading documents, or performing biometric verification.

​
Task lifecycle

Tasks move through different stages based on how the journey is configured:
  1. Assigned – The task is created and waiting for input.
  2. In Progress – The task has been started.
  3. Completed – The required data has been submitted and validated.

​
Task ID

Each task within a journey has a unique task ID, which you use to:
  • Retrieve the list of tasks assigned to a journey instance.
  • Fetch the schema that defines required data for a task.
  • Submit task data to progress the journey.

​
Task schema

A task schema defines the required fields and expected data structure for a task. The schema ensures that submitted data follows the correct format. If a journey is running in Prefill Mode, you must retrieve the schema from the Journey Dashboard in the GBG GO platform before starting the journey. The schema tells you:
  • Which fields must be included.
  • What data types are expected (string, array, object).
  • How identity information should be structured.
To retrieve and understand a schema, see the Retrieve the schema for prefill mode section.

​
Identity and user data in journeys

A context object holds structured user data, including:
  • Personal details: First name, last name, date of birth.
  • Contact information: Email addresses, phone numbers.
  • Address details: Current and previous addresses.
  • Government-issued IDs: Passport numbers, Social Security Numbers.
If you start a journey in Prefill mode, you must include a correctly structured context object. The system uses this data to auto-complete tasks that match the provided information. If any required fields are missing or invalid, pending tasks will be created.

​
User roles in GBG GO

There are two main user roles in the platform:
  • Business users design and configure customer journeys in the GBG GO platform. They define workflows, add verification modules, and publish journeys.
  • Developers integrate with the API to start journeys, retrieve tasks, and submit user data.
Business users focus on creating and managing customer journeys, while developers work on automation and data handling through API calls.

​
Authentication and security

​
Access tokens

To interact with the API, you must authenticate using an access token. This temporary credential is required for every API request.
  • Access tokens must be included in the Authorization header.
  • They expire after a set period and must be refreshed when they become invalid.
To obtain an access token, follow the Authentication guide.

​
Device connection

Some journeys require linking a customer’s session to a device. In such cases, the API provides a connection secret, allowing the device to:
  • Authenticate without requiring repeated logins.
  • Refresh its session securely.

​
Journey state and tracking

A journey state indicates the current status of an active journey instance. The most common states include:
  • In Progress: The journey is active, and tasks are pending.
  • Completed: The journey has been fully processed.
  • Pending Input: The journey is waiting for user action.
To monitor journey progress, retrieve the journey state using the API.