Skip to main content
The sample applications are working end-to-end integrations you run against your own GBG Go journey. Each one covers a different industry, but they’re built the same way, so the tutorial you pick is a starting point rather than a commitment. Each tutorial builds one journey, then lets you choose the backend. It can call the Journey API v2 directly or through the Core SDK, in Java or TypeScript. None of the sample apps uses a hosted journey.

Choose your sample application

Healthcare

Verify a patient’s identity during registration before granting access to medical records or services.

Banking

Run identity, document, and compliance screening checks as part of an account-opening flow.

Gaming

Confirm a player meets the age requirement for your jurisdiction before they can deposit or play.
The API work is much the same across the three, so a tutorial from a neighbouring industry still gives you a working integration to adapt. What differs is the journey you build first: which modules run, and how the evaluation turns their outcomes into a decision.

The repositories

The source for this sample app is on GitHub: Each backend repository holds two implementations of the same service, in separate folders:
  • api-implementation/ calls the Journey API with hand-written HTTP requests.
  • sdk-implementation/ calls the Journey API through the Core SDK.
You need the front end and one backend. Every backend exposes the same HTTP API, so the front end works with any of them. Each backend holds all three sample apps as separate configurations, so cloning it once covers whichever tutorial you follow. The front end works the same way.

How the applications are built

Every sample app has a React front end and a backend service. The backend comes in four versions, in Java or TypeScript, calling the Journey API directly or through the Core SDK. You choose one, and the front end is the same either way. The front end never talks to GBG Go directly. It calls your backend, and the backend holds the credentials and calls the Journey API. This keeps your client secret out of the browser, which is the only safe arrangement for a developer-first integration. The screens are not hardcoded. Each one renders from what your journey says it collects, so adding a field in the Journey builder makes it appear in the app without a code change. This is the part worth carrying into your own integration, and it’s why each tutorial starts by building the journey. The request flow below is what you’d adapt for your own application.
1

The backend starts a journey

When a customer opens the app, the backend calls journey/start with your resource ID and delivery: "api", and gets back an instanceId. It stores that against its own session ID and gives the browser a session cookie. The instance ID never reaches the browser.
2

The screens come from the journey

The backend calls journey/interaction/fetch and reads the collects list, which names every domain element the interaction can collect, each marked required or optional.The response also has an outstanding list, which is narrower. It names only what Go is currently blocking on, and omits any element whose parent group is optional. A client that renders from outstanding alone drops any screen whose elements sit under an optional parent.The sample’s screen plan maps those elements onto screens, matching on element names rather than page numbers, so adding a field in the Journey builder makes it appear in the app without a code change.
3

Each screen submits what it collected

journey/interaction/submit takes two things, a participants list naming the domain elements, and the values themselves under context.subject. Document and selfie images travel inside that payload as base64. There is no separate upload endpoint.
4

The app waits for the checks

After the document and selfie, the modules run. The app polls journey/state/fetch until the journey settles.While Document Classification decides whether it needs the back of the document, the fetch carries the instruction LazySide2CollectionRequired, and the app holds on a processing screen until that resolves to Side2Required or Side2Done.A journey referred to manual review stays InProgress indefinitely with ManualReviewDecision in outstanding. The app treats that as settled and shows the referral, because no amount of polling will change it.
5

The result screen

Once the journey settles, the app fetches the record and shows the decision, the checks that ran, and how long each took.

How the API backends call GBG Go

The API backends call the Journey API directly, with hand-written HTTP requests. Each step is one POST: The token calls are in GoTokenService.java or goTokenService.ts, and the journey calls are in GoApiClient.java or goApiClient.ts. Both sit in the backend’s go/live folder. Your own API integration needs to handle the same things the API backends do:
  • Reuse the access token. The backend requests a token once and reuses it until 30 seconds before it expires.
  • Send the token on every journey call. Each request carries an Authorization: Bearer header and a JSON body.
  • Retry once on a rejected token. When GBG Go answers 401 or 403, the backend requests a new token and retries the call once.
  • Set a timeout. The backend stops waiting for GBG Go after 15 seconds, so a stalled call can’t hold up the customer.
  • Map each field onto the subject. The backend places each front-end field at its path under context.subject. A field with no mapping goes under its own name at the top of context.subject.

How the SDK backends call GBG Go

The SDK backends follow the same request flow as the API backends. What changes is that each Journey API call becomes an SDK method: The token calls are in GoSdkAuthService.java or goSdkAuthService.ts, and the journey calls are in GoSdkClient.java or goSdkClient.ts. Both sit in the backend’s go/sdk folder. Your own SDK integration needs to handle the same things the SDK backends do:
  • Interaction calls take their own token. interactions.fetch and interactions.submit don’t use the client’s customerAccess token. The backend passes the access token as interactionAccess on every call.
  • Responses arrive as one of several variants. Fetch and state responses are a full view, a slim view, or an unknown variant. The backend reads the full view, because only the full state view carries each module’s status and timing.
  • The SDK types the data you submit. It removes any key that has no field on its subject type. The backend maps each front-end field onto the SDK’s types, and logs a field it can’t map.
  • Retries are off. Start and submit must not run twice, so the backend never retries them. When GBG Go rejects the access token with 401 or 403, the backend requests a new token and retries once.
The SDK backends serve the same HTTP API as the API backends, but two behaviours differ:
  • The SDK backend leaves out a field it can’t map. The API backend sends an unmapped field under its own name at the top of context.subject. The SDK backend has nowhere to put it, so it logs the field and leaves it out. With either backend, add a new kind of field to the submit mapping.
  • Saved test scenarios aren’t available. The SDK can’t send the x-gbg-scenario header, so the SDK backend can’t start a saved test scenario by name.

What you need

Every sample app tutorial assumes:
  • Access to the Go dashboard, with permission to create and publish journeys.
  • Licences for the modules this tutorial uses. Licences are assigned to your department by GBG, and an unlicensed module shows a warning icon in the Journey builder.
  • An API client. See Manage API clients for how to create one and get your client ID and secret.
  • Node.js v18 or higher, for the front end and the TypeScript backend.
  • JDK 21 and Maven, only if you choose the Java backend.
  • Git, to clone the sample repositories.
Each tutorial also names the modules its own journey uses, so you can check those licences before you start.

Running against Preview or Production

The sample apps work the same against either environment. Only the resource ID changes. Use Preview while you build and test, then publish to Production when you’re ready for real customers. See Publish a journey.
Pin the exact version as <resourceId>@<version> rather than using @latest. Every republish creates a new version, and a pinned application keeps running the version you tested until you change it deliberately.

Next steps

Start with a sample app

The healthcare tutorial is the shortest journey, so it’s the quickest way to see the whole chain working.

Explore the API

The full Journey API v2 reference.