Skip to main content
GO Hosted journeys provide a platform-managed delivery method for your customer verification workflows. Instead of building and maintaining a custom frontend to collect end-user data, the GBG GO platform hosts the verification pages on your behalf and serves them through secure, authenticated URLs. With Hosted journeys, your server makes a single API call to start a journey and receives an authenticated link known as an instance URL. You share this URL with your end users by embedding it in your app, which then redirects the end user to the GBG GO platform. The platform renders the verification screens, collects the required information, and processes it through your configured journey flow, all without requiring custom frontend development.

​
Core concepts

Below are the key concepts to understand when working with GO Hosted journeys:
  • Interaction journeys: A verification journey configured to collect information directly from end users through hosted pages. It combines processing modules, interaction nodes (screens), and flow control logic.
  • Hosted pages: Platform-generated web interfaces served by GBG GO that render verification screens, collect user input, and process it through the configured journey flow.
  • Instance URL: A secure, authenticated link returned when your server starts a journey via the API. You share this URL with end users to direct them to the hosted verification experience.
  • Domain elements: Individual pieces of information required by verification modules for example, first name, last name, and date of birth. The platform auto-generates interaction nodes based on the domain elements your configured modules need.
  • Interaction groups: A collection of related data fields and pages that the platform presents to end users as a single block within a journey flow. Each interaction group contains the domain elements the journey needs to collect and organises them into pages with manageable screens. This grouping consolidates data collection into a clear, sequential set of screens rather than requesting information at multiple unrelated points in the flow.
  • Delivery method: The classification of how a journey reaches end users. At the moment, Hosted journeys are categorised as low-code because they require a single API call to start but handle all frontend rendering and orchestration on the platform side.
  • Interaction Group panel: A visual panel for authoring the UI resources that define what end users see on hosted pages, including branding, localisation, and form layout.
For a broader overview of hosted journey concepts refer to Key concepts.

​
Why use Hosted journeys?

When you integrate with the GBG GO API using the default API method, your development team is responsible for building the entire end-user experience. This includes:
  • Designing forms
  • Handling field validation
  • Managing screen transitions
  • Capturing documents and biometrics
Hosted journeys shift this responsibility to the GBG GO platform. The platform generates and manages the verification screens based on your journey configuration, which means:
  • Your team does not need to build or maintain a verification frontend.
  • Screens update automatically when you modify your journey configuration and republish.
  • You retain full control over the verification logic, evaluation decisions, and module configuration in the journey designer.
This makes hosted journeys particularly suitable for teams that want to launch verification workflows quickly, lack dedicated frontend resources, or need to reduce ongoing maintenance overhead.

​
Who should use Hosted journeys

Hosted journeys are designed for teams that want to deploy verification workflows without investing in custom frontend development. They are well suited for:
  • Business users who configure journeys and want to see them live quickly without waiting for development resources.
  • Developers who want to integrate verification with minimal frontend effort. All that’s needed is a single API call to start the journey, plus a redirect mechanism.
  • Organisations evaluating GBG GO who want to test verification workflows end-to-end without building an interface first.

​
How Hosted journeys work using Low-code delivery

The term “Low-code” means that you still need a small amount of server-side development to start the journey using the API, but you don’t need to build the end-user interface. The steps below highlight how Low-code delivery works:
1

Create a Hosted journey

Create a Hosted journey using the Journey builder.
2

Start the journey via API

Configure your server to call the GBG GO /journey/start endpoint with the journey’s resourceId and the page configuration option. This starts the journey.
3

Receive the instance URL

The API response contains instanceId + instanceUrl. To learn more, refer to API usage guides.
4

Redirect the end user

Your application redirects the end user to the instanceUrl.
5

Platform loads verification screens

The GBG GO platform loads the verification screens.
6

End user completes verification

The end user completes each screen by submitting relevant data in each field, for example, personal details, contact information, document uploads, or biometric capture.
7

Redirect back to your application

When the journey completes, the end user is redirected back to your application.
Throughout this process, your server can continue to use the API to monitor journey progress, fetch journey status, and receive data through configured callbacks.
Note that the instanceUrl is only valid for a limited time. If you are using a hosted journey in a production environment, make sure to redirect the user to the instanceUrl immediately after receiving it from the API response.

​
Hosted journeys and API-first integration

GBG GO supports two delivery methods for customer journeys: API-first and hosted journeys. Both methods use the same underlying journey configuration, modules, and evaluation logic. The difference is in how end-user data is collected.
  • API-first: This is the default delivery method. Your application collects all end-user data through your own frontend and submits it to the API. You have complete control over the user experience, and you are responsible for building and maintaining the interface.
  • Hosted journeys: This lets the GBG GO platform handle the end-user interface. The platform generates screens based on the data your journey requires and presents them to the end user through hosted pages on the GBG GO domain.

​
What Hosted journeys include

When you enable hosted journeys for a journey, the platform generates interactive screens to collect the data your modules require. These screens are called interactions, and they appear as nodes in the journey flow within the designer. Hosted journeys support a growing range of interaction types. Here are some examples:
  • Personal details: Collects the end user’s first name, last name, and date of birth.
  • Contact information: Collects the end user’s phone number and email address.
  • Document upload: Allows the end user to upload identity documents such as a passport or driving licence.
These are not the only interactions available. The platform continues to expand the types of interactions it supports, and a full reference will be available soon.
The platform determines which interaction screens to generate based on the input fields required by each module variant in your journey. Screens contain no more than five fields each, and the platform organises them to collect data in the order it is needed. This reduces friction and minimises the chance of end users abandoning the process.

​
Frequently asked questions

The journey still works and can be started. Any domain element that does not yet have a card in the hosted experience goes into pre-fill, so you supply it through the API at journey start instead of collecting it on a hosted screen.
The journey still works and can be started. However, if the fields for that domain element are not provided through the API when the journey starts, the journey cannot complete. Make sure you supply any removed but required domain elements at journey start.
Not currently. There is no automated way to convert an existing v1 API journey into a v2 hosted journey. To use hosted journeys, build the journey in v2.
You can restart a journey only while its link is still valid. Once the link expires, the journey cannot be restarted and you need to start a new one.

​
Next steps

API usage guides

Learn how to authenticate, start a hosted journey, share the instance URL, and fetch journey state using the API.