Overview
The journey URL is the web address yourWebView loads to start an identity verification flow. It is not hardcoded β your backend generates it at runtime using the GBG Go Core SDK (@gbg/go-core).
The Android app never calls the Core SDK directly. Session creation happens server-side, and the app receives the URL through whatever API your backend exposes.
Core SDK setup
Installation
Authentication
The Core SDK authenticates with a customer access token (Bearer). Generate one using the SDKβs token endpoint:Regional servers
| Index | Region | Server |
|---|---|---|
| 0 | EU | https://eu.platform.go.gbgplc.com/v2/captain |
| 1 | US | https://us.platform.go.gbgplc.com/v2/captain |
| 2 | AU | https://au.platform.go.gbgplc.com/v2/captain |
serverIdx, or provide a custom serverURL.
Create a journey session
Journey URL generation is a two-step process.Step 1: Start the journey
Callgo.journeys.start() with a resource ID that identifies which journey template to run:
resourceId uses the format <id>@<version> β use @latest to always get the current version of the journey template.
Pre-populate context (optional)
You can pass identity data, documents, biometrics, and consent records in thecontext field. This pre-populates the journey so the end user doesnβt have to re-enter information you already have:
Step 2: Get a connect token
For native app integrations, generate a connect token that the device uses for authentication:connectToken is short-lived (typically 120 seconds). Your backend should return it to the Android app immediately after generating it.
Construct the URL
How you get the final URL to load in theWebView depends on your integration pattern:
- If the
instanceUrlis present in the Step 1 response, use it directly. - Otherwise, your backend constructs the URL from the
instanceIdandconnectTokenaccording to your deploymentβs URL scheme.
Load the URL in Android
Once the Android app has the URL from your backend, attach aBridgeHost to a WebView and load it. In Compose:
WebView, call host.attach(webView), then webView.loadUrl(journeyUrl).
The bridge handles everything else β attach() configures the WebView (JavaScript, DOM storage, the bootstrap-injecting WebViewClient) and registers the JavaScript interface, so bootstrap injection and capability negotiation happen automatically when the page loads.
Complete backend example
A minimal Express endpoint that creates a journey session and returns the URL:The Android reference app ships a companion server (under
server/) that implements exactly this pattern. It runs on port 3000 and exposes POST /api/journey/start (body { resourceId? }) plus GET /api/journey/:instanceId/state for fetching the journey outcome after completion.When developing against a backend on your own machine, remember that the Android emulator routes
localhost / 127.0.0.1 to the emulator itself β not the host. Use the loopback alias http://10.0.2.2:3000 to reach a server running on the host machine, or run adb reverse tcp:3000 tcp:3000 and keep using 127.0.0.1. Android also blocks cleartext HTTP by default (API 28+), so scope a network_security_config.xml exception to 10.0.2.2/localhost for local development rather than enabling cleartext traffic globally.Security considerations
- Never embed the customer access token in the Android app. It is a server-side secret. The Android app only ever sees the journey URL (and optionally the connect token).
- Always use HTTPS in production.
- Connect tokens are short-lived (typically 120 seconds) and single-use. Donβt cache or persist them.
- The journey URL should be treated as sensitive β donβt log it or store it beyond the current session.
- Fetch the URL over an authenticated channel between your app and your backend (e.g., behind your own auth middleware).
Next steps
- Integration Checklist β End-to-end setup walkthrough
- Embedding Guide β Compose and View-system patterns for displaying the journey
- Capture Screens β Get a working capture flow without Smart Capture SDKs