Skip to main content
This page explains how the GBG Go platform works. If you’re a business user, then you design workflows and configure verification steps. If you’re a developer, then you integrate with the API to start journeys, retrieve tasks, and submit customer data. To see how a journey runs from build to review, see Get started with GBG Go.

​
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. GBG Go evaluates outcomes and decisions in order from top to bottom. When a condition matches, GBG Go returns that result and stops processing. For example, in a NameMatch module, if customer names match, then the system returns the IsNameMatch outcome. In this case, the outcome has a configuration of Does name match = is true. The system skips all remaining configured outcomes or decisions.

​
Journey instance

When a journey starts, the system creates a journey instance, which represents an active execution of a customer journey. The system gives each instance 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: You send customer data upfront when you start a journey. The system can auto-complete matching tasks based on the data provided.
  • Non-prefill mode: You start a journey without customer data. You send an empty context object, and customers provide required details through tasks later.

​
Linear and adaptive journey processing

GBG Go processes a journey in one of two ways:
  • Linear processing: The journey follows a fixed sequence of steps. The end user completes each task in order before moving to the next.
  • Adaptive processing: The journey adjusts to customer data and verification results. It might skip or add tasks depending on the context. It collects data in order of the journey stage, which tailors the verification process.

​
Resource ID and journey versions

A resource ID identifies a specific journey version. When you publish a journey, it receives a unique resource ID. To start a journey, you provide this ID in the request. To start the most recent published version, append @latest, for example, your-resource-id@latest. If your integration requires a specific version, then 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 might involve providing identity details, uploading documents, or performing biometric verification.

​
Task lifecycle

Tasks move through different stages, depending on the journey configuration:
  1. Assigned: The system creates the task, and it waits for input.
  2. In Progress: The end user has started the task.
  3. Completed: The end user has submitted the required data, and the system has validated it.

​
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 runs in prefill mode, then retrieve the schema from the Journey Dashboard before you start the journey. The schema tells you:
  • Which fields to include.
  • The data type each field expects, such as string, array, or object.
  • How to structure identity information.
To retrieve and understand a schema, see Start a journey in prefill mode.

​
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, then 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, then the system creates pending tasks.

​
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

Your server authenticates with an access token, and some journeys also connect the end user’s device.

​
Access tokens

To interact with the API, you authenticate with an access token. Every API request needs this temporary credential.
  • Include the access token in the Authorization header.
  • Access tokens expire after a set period, so refresh them 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.

​
Partner organisations

GBG Go supports a parent-child organisation structure, so a single top-level organisation can own resources and share them with the organisations beneath it.

​
Partner organisation

A partner organisation is a top-level organisation that owns and manages resources, such as journeys, flows, and deliveries, on behalf of its child organisations. A partner organisation can share the journeys it owns with its sub-organisations automatically, without duplicating the underlying resources.

​
Sub-organisation

A sub-organisation, also called a child organisation, is an organisation that belongs to a partner organisation. It receives shared resources from its parent while keeping its own execution context, so journeys run independently within each sub-organisation.