> ## Documentation Index
> Fetch the complete documentation index at: https://docs.go.gbgplc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sample applications overview

> How the GBG Go sample applications are built, what they share, and which one to start with.

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

<CardGroup cols={3}>
  <Card title="Healthcare" icon="hospital" href="/docs/go-v2/tutorials/healthcare-patient-onboarding">
    Verify a patient's identity during registration before granting access to medical records or services.
  </Card>

  <Card title="Banking" icon="building-columns" href="/docs/go-v2/tutorials/banking-account-opening">
    Run identity, document, and compliance screening checks as part of an account-opening flow.
  </Card>

  <Card title="Gaming" icon="dice" href="/docs/go-v2/tutorials/gaming-age-verification">
    Confirm a player meets the age requirement for your jurisdiction before they can deposit or play.
  </Card>
</CardGroup>

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.

| Sample app | Industry | What the journey does |
| - | - | - |
| [Patient onboarding](/docs/go-v2/tutorials/healthcare-patient-onboarding) | Healthcare | Six modules verify a document and selfie, match the patient's details, and record consent |
| [Account opening](/docs/go-v2/tutorials/banking-account-opening) | Banking | Eight modules add PEPs and sanctions screening, a risk score, and address verification, with a manual review branch a person resolves |
| [Age verification](/docs/go-v2/tutorials/gaming-age-verification) | Gaming | Nine modules confirm the player's age and screen for financial vulnerability |

## The repositories

The source for this sample app is on GitHub:

* [go-sample-frontend](https://github.com/gbgplc/go-sample-frontend): the React front end, shared by all three sample apps.
* [go-sample-backend-java](https://github.com/gbgplc/go-sample-backend-java): the Java backend.
* [go-sample-backend-typescript](https://github.com/gbgplc/go-sample-backend-typescript): the TypeScript backend.

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/docs/go-v2/platform/account-management/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](/docs/go-v2/platform/journey-builder/publish-journey).

<Warning>
  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.
</Warning>

## Next steps

<CardGroup cols={2}>
  <Card title="Start with a sample app" icon="play" href="/docs/go-v2/tutorials/healthcare-patient-onboarding">
    The healthcare tutorial is the shortest journey, so it's the quickest way to see the whole chain working.
  </Card>

  <Card title="Explore the API" icon="code" href="/docs/go-v2/api-reference/endpoint/start-journey">
    The full Journey API v2 reference.
  </Card>
</CardGroup>