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. The API sample applications below use the Journey API v2 directly, with no SDK and no hosted journey. SDK sample applications will be documented separately when those versions are available.

​
Choose an API 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: You need the front end and one backend. Both backends expose the same HTTP API, so the front end works with either. 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 API sample app has a React front end and a backend service, available in both Java and TypeScript. You choose one backend, 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 an API-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.

​
What you need

Every API 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.