Skip to main content

Overview

This quickstart guides you through the following:
  • Create a journey with the PEPs and Sanctions module.
  • Set up authentication.
  • Execute your first customer journey.
  • Retrieve tasks, submit data, and confirm the journey completes.
This guide walks you through integrating customer verification workflows into a frontend application using the GBG GO API.

Prerequisites

Before running this quickstart, complete the following:
  • You have created an API client in the Account management portal. Your API client provides the credentials required to authenticate your API requests:
    • client_id: Your unique API client identifier.
    • client_secret: Your secret key for API authentication.
    For instructions on creating an API client, see Manage API clients.
API client credentials are different from your personal GBG GO platform login. API client credentials are specifically for programmatic access and should not be confused with the username and password you use to log into the GBG GO dashboard.
  • You have a development environment capable of making HTTP requests, for example, Postman.

Step 1: Create a journey with the PEPs and Sanctions module

Before you can execute a journey using the API, you need to create one in the GBG GO platform. In this quickstart, you’ll use the PEPs and Sanctions module, which screens individuals against global watchlists for Politically Exposed Persons (PEPs) and sanctioned entities. This helps your organisation meet Anti-Money Laundering (AML) and Counter-Terrorism Financing (CTF) obligations. When a customer’s data is submitted, the module compares it against international databases and returns a result, either a hit (match found), no hit (no match), or not available. To create the journey:
  1. Log in to the GBG GO platform and create a new journey in the journey builder.
  2. Click Browse and add modules.
  3. Search for PEPs and Sanctions or navigate to the Compliance Screening category.
  4. Select the PEPs and Sanctions module and choose the UK Instance (with Adverse Media and OGM) variant.
  5. Click Add to journey.
  6. Click Configure outcomes and set up rules for match and no-match results. For example, set the outcome to “Match” when PEPs and Sanctions Results is PEPs and Sanctions Hit.
  7. Publish the journey to Preview.
  8. Note the journey’s resource ID and version from the journey dashboard. You’ll need these for the API calls. See Publish a journey for details on how to find these values.
For a detailed guide on configuring the PEPs and Sanctions module, including variant options and outcome rules, see Understanding the PEPs and Sanctions module.

Step 2: Request an access token for authentication

Make a POST request to obtain your Bearer token:
cURL
You’ll receive an access token that you’ll use for all subsequent API calls, like this:
JSON
Store the access_token value securely. Do not share them in emails, chat messages, client-side code or publicly accessible sites.
If you run into a credentials error when making a token cURL request, then your client ID or client secret probably aren’t correct. Check the values in the Account management portal, or regenerate the client secret if needed. See Manage API clients.

Step 3: Start your first customer journey

Use your access token and the journey resource ID from Step 1 to start a journey. Make a POST request to the (/journey/start) endpoint:
cURL
You are checking the name John Michael Doe, born on June 1, 1961, against the PEPs and Sanctions databases. You’ll receive an instanceId that represents your active journey:
JSON
Save this instanceId — you’ll need it for every subsequent step.
Replace your-journey-resourceID@version with the resource ID and version from Step 1. For example: "resourceId": "092a0947e99aa3e955344178a3d010413769e0acca6d97728dd758e04b449566@7upcgqlz".

Step 4: Retrieve task IDs

After starting a journey, GBG GO assigns tasks based on the modules in your journey. Retrieve the task IDs to find out what needs to be completed. Send a POST request to the /journey/task/list endpoint using the instanceId from Step 3:
cURL
You’ll receive a list of tasks assigned to the journey:
JSON
Note the taskId. You’ll use it in the next step to retrieve the task’s schema and to submit data.

Step 5: Retrieve tasks with their schema

Now fetch the tasks along with their corresponding JSON schema using the taskId. This tells you the exact fields you need to submit for each task, in a single API call. Send a POST request to the /journey/task/list/schema endpoint:
cURL
You receive the tasks with a schema reference and the full schema definitions:
JSON
If you didn’t have the name John Michael Doe and date of birth June 1, 1961 in the initial context when starting the journey, the task schema would indicate that these fields are required for the task to be completed. Use this schema to understand what data you need to collect from the user to complete the task. In this case, you would need to collect the user’s first name, last name, and date of birth, to complete the task. Use this information to build out your frontend and collect the required data from the user. Each task’s schema.$ref points to a key in the schemas map. The schema defines the full context structure you need to submit, including required fields and data types. Use this to build your submission payload in the next step.
For more details on reading and using task schemas, see Manage schemas and the User data schema reference.

Step 6: Submit task data

Use the taskId from Step 4 and the schema from Step 5 to submit the required customer data. Send a POST request to the /journey/task/update endpoint:
cURL
The "intent": "Complete" field is required to mark the task as finished. The fields in context depend on your journey’s task schema. Use the Manage schemas guide and User data schema reference to see the exact structure for your journey.
If the journey has more tasks, then repeat Step 4 to Step 6 until no tasks remain.

Step 7: Fetch journey state

After submitting all task data, check whether the journey has completed. Send a POST request to the /journey/state/fetch endpoint:
cURL
When the journey completes, you’ll receive a response like this:
JSON
The journey state response contains the full state and result of the journey. The exact result payload differs by module, but the top-level structure is consistent across journeys.

Top-level fields

Subject and process

Module result (flow.<module>.result)

PEPs and Sanctions advice

PEP and sanctions match details (note.pep_match_details, note.sanctions_match_details[])

Adverse media match details (note.adverse_media_match_details)

The advice and note shapes vary per module. For the exact schema returned by each module variant, see Modules.
The result above shows a completed journey with the final outcome of “MATCH”. The status field indicates that the journey has completed successfully. The context field contains the full data context of the journey, including all information about the subject, process, and results from any modules or steps in the journey. John’s full name and date of birth were successfully verified, resulting in a “hit” for sanctions screening. The module returned a match with a sanctions list and adverse news articles, providing detailed information about the match and related news articles. When you see "status": "Completed", the journey is done and your integration is working end to end.
If the status is InProgress, then go back to Step 4 to retrieve and complete remaining tasks.

Next steps

Now that you’ve completed a full journey execution from start to Completed, check out the following guides to learn more: