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.

Account and access

If you have forgotten your password:
  1. Go to the GBG GO sign-in page.
  2. Click Forgot your password? on the login screen.
  3. Check your email for a recovery code and enter it in the recovery code field.
  4. Enter a new password and confirm it.
  5. Click Change Password to save your new password.
GBG GO provides two separate environments:
  • Preview environment: A test environment where you can validate journeys before deploying them to production. Use this to test API calls, verify journey behaviour, and confirm that modules are configured correctly.
  • Production environment: The live environment where published journeys are used by real customers.
To publish a journey to the preview environment:
  1. Open your journey in the Journey builder.
  2. Click Publish to Preview.
  3. A confirmation message appears: “Delivery deployed successfully”.
  4. Click Dashboard, where you can see the environment label (Preview), version number, resource ID, last published date, and the auto-generated schema.
To access preview data in the Investigation portal:
  1. Navigate to Investigation.
  2. Click the Preview Environment tab.
The preview environment uses a separate resource ID from production. When testing your API integration, use the preview resource ID from the Dashboard. Once testing is complete, publish the journey to production to generate a production resource ID.

Core concepts

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.

Starting a journey

The config object is included inside context when you start a journey. It controls how the journey is delivered to the end user.The primary value you can set is delivery, which determines the delivery mode:
  • page: Use this for GBG hosted journeys (low-code). When delivery is set to "page", the start response includes an instanceUrl, which is a GBG-hosted page URL that you redirect the end user to. The platform handles the entire user interface.
  • api: Use this for API-first integration. When delivery is set to "api", the start response does not include an instanceUrl. You are responsible for building the user interface and collecting data from the end user.
Example with hosted delivery:
JSON
{
  "resourceId": "your-resource-id@latest",
  "context": {
    "config": {
      "delivery": "page"
    },
    "subject": {}
  }
}
Example for API-first integration:
JSON
{
  "resourceId": "your-resource-id@latest",
  "context": {
    "config": {
      "delivery": "api"
    },
    "subject": {}
  }
}
The uid field is an optional string inside context.subject that allows you to associate a journey instance with a specific user in your system. It acts as a correlation identifier, linking the GBG GO journey to an existing customer or user record on your side.For example, if your system assigns each customer a unique ID like user-12345, you can pass it as the uid when starting a journey:
JSON
{
  "resourceId": "your-resource-id@latest",
  "context": {
    "config": {
      "delivery": "api"
    },
    "subject": {
      "uid": "user-12345"
    }
  }
}
This is useful for:
  • Traceability: Matching journey results back to the correct customer record in your system.
  • Debugging: Identifying which user a journey instance belongs to when investigating issues.
  • Reporting: Correlating GBG GO verification outcomes with your internal user data.
The uid field is not required and does not affect journey processing. If you do not need to correlate journeys with an external system, you can omit it.

Submitting data

In the v2 API, documents are submitted inside context.subject.documents as part of an interaction submission. Each document object includes a base64-encoded image for each side and a type field.Example: Submitting the front of a primary document:
JSON
{
  "instanceId": "your-instance-id",
  "interactionId": "your-interaction-id",
  "participants": [
    { "domainElementId": "PrimaryDocument" }
  ],
  "context": {
    "subject": {
      "documents": [
        {
          "side1Image": "<base64-encoded-image>",
          "side2Image": "",
          "type": "Primary"
        }
      ]
    }
  }
}
Field reference:
FieldDescription
side1ImageBase64-encoded image of the front of the document.
side2ImageBase64-encoded image of the back of the document. Leave as an empty string if not applicable.
typeThe document type. Use "Primary" for the main identity document.

Submitting a selfie

Biometric data such as a selfie is submitted separately inside context.subject.biometrics:
{
  "instanceId": "your-instance-id",
  "interactionId": "your-interaction-id",
  "participants": [
    { "domainElementId": "Selfie" }
  ],
  "context": {
    "subject": {
      "biometrics": [
        {
          "selfieImage": "<base64-encoded-image>"
        }
      ]
    }
  }
}
Documents and biometrics must be placed inside context.subject. Placing them outside subject causes the request to fail.
Partial submissions are supported. You can submit documents and biometrics in separate calls to the same interaction. Use the outstanding field in the interaction fetch response to track which domain elements still need to be provided.
Identity data is submitted inside context.subject.identity as part of an interaction submission. You only need to include the fields relevant to your journey’s requirements.

Submitting a Social Security Number (SSN)

SSN is submitted as an entry in the idNumbers array with a type of "ssn":
JSON
{
  "instanceId": "your-instance-id",
  "interactionId": "your-interaction-id",
  "participants": [
    { "domainElementId": "SSN" }
  ],
  "context": {
    "subject": {
      "identity": {
        "idNumbers": [
          {
            "idNumber": "123-45-6789",
            "type": "ssn"
          }
        ]
      }
    }
  }
}

Submitting date of birth only

The response below shows how to submit just the date of birth if that’s the only required field for your journey.
JSON
{
  "instanceId": "your-instance-id",
  "interactionId": "your-interaction-id",
  "participants": [
    { "domainElementId": "DateOfBirth" }
  ],
  "context": {
    "subject": {
      "identity": {
        "dateOfBirth": "1990-01-01"
      }
    }
  }
}

Submitting partial identity data

Partial submissions are supported for identity data. This means you can submit a subset of the required identity fields in one API call, and then submit the remaining fields in subsequent calls as you collect them from the end user. Use the outstanding array in the fetch interaction response to track which identity fields still need to be submitted.For example, if your journey requires FullName, DateOfBirth, and PrimaryDocument, you could first submit just DateOfBirth, then check the next fetch interaction response to see that FullName and PrimaryDocument are still outstanding, and submit those in the next call. Refer to partial prefill mode in Step 2: Start a journey for how to submit partial identity data when starting a journey.

Errors and troubleshooting

To authenticate, send a POST request to the token endpoint:
JSON
https://api.auth.gbgplc.com/as/token.oauth2
The request must be sent with the following parameters:
ParameterDescription
client_idThe client ID.
client_secretThe client secret.
usernameYour API username.
passwordYour API password.
grant_typeSet to password.
Example request:
BASH
curl --request POST \
  --url https://api.auth.gbgplc.com/as/token.oauth2 \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data 'client_id=your-client-id&client_secret=your-client-secret&username=your-username&password=your-password&grant_type=password'
A successful response returns:
{
  "access_token": "your-access-token",
  "token_type": "Bearer",
  "expires_in": 3600
}
Include the token in the Authorization header of subsequent API request as Bearer your-access-token. Store the token securely and refresh it before it expires.You can obtain your API credentials (client ID, client secret, username, and temporary password) from your GBG account manager.
You can access detailed failure reasons in two ways:
  • Through the v2 API error response
  • Through the Investigation portal.

v2 API error responses

The v2 API returns structured error objects that include a machine-readable error code, a description of the problem, and a recommended action. Each error specifies where the issue originated, making it easier to diagnose failures programmatically.
{
  "errors": [
    {
      "code": "4002",
      "name": "MISSING_FIELD",
      "location": "Body",
      "problem": "problem description goes here",
      "action": "action to resolve the issue goes here"
    }
  ]
}
FieldDescription
codeNumeric error code (returned as a string).
nameMachine-readable error identifier (for example, MISSING_FIELD).
locationWhere the error originated: Body, Authorization, Path, or Service.
problemA description of what went wrong.
actionWhat you should do to resolve the error.
Every API response also includes an X-Request-ID header. Include this value when contacting GBG support. It correlates your request with server-side logs for faster troubleshooting.

Investigation portal

For document-specific verification failures, the Investigation portal provides the most detailed view. To access granular failure reasons:
  1. Log in to the GBG GO platform and navigate to the Investigation section.
  2. Click the Session ID of the session you want to review. This opens the session detail view, which shows an overview of the session.
  3. Navigate to the Processing tab to see each module’s outcome, for example, Match, No Match, or Error.
  4. Expand any module section to see a breakdown of individual data point matches.
  5. Click More details to open the module detail view. The available tabs vary by module type.
  6. Check the Raw Response tab for the complete response from the verification provider, which contains the module errors and reasons.

Platform

The audit log records a chronological history of actions taken during a verification session. You can view the audit log for any session in the Investigation portal by navigating to the Audit Log tab within a session’s detail page.The audit log displays the following information for each recorded action:
ColumnDescription
Date and timeWhen the action occurred.
UserWho performed the action.
ActionThe specific action taken for example, changing a verification decision.
DataAdditional details about the action.
For example, if a reviewer changes a session’s decision from rejected to accepted, the audit log records who made the change, when it happened, and any notes associated with it.You can sort the audit log by date to review events in chronological order, and use the page navigation controls at the bottom to move between pages of results.

Contact

If you can’t find the answer to your question, see Troubleshooting and support for ways to get in touch with the GBG team.