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. You can deliver a Hosted journey to your end users in two ways:
  • Low-code: 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.
  • No-code: You invite one customer at a time from the GBG Go platform. You enter their contact details and the platform sends them a verification link. You write no code and make no API calls.
Both options use the same published journey, the same modules, and the same platform-hosted pages. They differ only in how the journey starts and how the link reaches your end user.

​
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. Hosted journeys handle all frontend rendering and orchestration on the platform side. They are delivered either as low-code, which requires a single API call to start, or as no-code, which you start from the GBG Go platform.
  • Single user invite: A no-code invite sent from the GBG Go platform to one customer. The platform delivers a verification link by email, text message, or both.
  • 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.
  • Customer-facing teams who verify one customer at a time, such as support agents onboarding a new client or compliance staff running a check on request. No-code delivery suits this work because it needs no integration at all.
  • Organisations evaluating GBG Go who want to test verification workflows end-to-end without building an interface first.
  • Organisations evaluating GBG Go who want to test verification workflows end-to-end without building an interface first.

​
How Hosted journeys work

Hosted journeys reach your end users through one of two delivery options. Expand the option that suits you:
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.To make these server-side calls without writing request boilerplate, you can use the Core SDK. It starts the journey, returns the instance URL, and fetches journey state through a type-safe TypeScript client. If you want to embed the hosted journey in your own app rather than redirect to it, then refer to the Bridge SDKs for iOS, Android, and web.
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.
The term “No-code” means that you neither build the end-user interface nor write any server-side code. You start the journey and send the invite from the GBG Go platform.The steps below highlight how No-code delivery works:
1

Create and publish a Hosted journey

Create a Hosted journey using the Journey builder, and then publish it to an environment.
2

Invite your customer

Open the journey in the dashboard and send an invite to your customer’s email address, mobile number, or both.
3

Platform sends the link

The GBG Go platform sends your customer a verification link.
4

End user completes verification

Your customer opens the link and completes each screen by submitting relevant data in each field.
5

Review the outcome

Review the verification results and decision in Investigate.
No-code delivery invites one customer per action, and the invite is valid for that one customer. To send your first invite, see the No-code quickstart.
No-code delivery requires a licence and credentials for the User Invite module. The journey must also be published, and it can’t collect information before it starts. For the conditions that hide the invite action, see When the invite action is unavailable.

​
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.

No-code overview

Invite a single customer to a published journey from the GBG Go platform, without writing code.

Core SDK

Start hosted journeys and fetch journey state from your server with a type-safe TypeScript client.