Overview

Official SDKs for integrating GBG GO into your applications

GBG GO provides two distinct types of SDK. Which one you need depends on where your code runs and what you’re building: the Core SDK for talking to our API from your backend, and the Bridge SDKs for embedding a hosted journey in your app or website. Many integrations use both together.

The two types of SDK

Core SDK

A generated, type-safe client for the GBG GO API. Runs on your server to authenticate, start journeys, and exchange data.

Bridge SDKs

Native and web hosts that embed a hosted GBG GO journey in your app or website and let it reach device capabilities.

Core SDK — call our API from your server

The Core SDK (@gbg/go-core) is a wrapper around the GBG GO API. Its job is to make those APIs easy to call: it removes the boilerplate of building requests, handling auth, and parsing responses, and it gives you a type-safe surface to work against.

Use the Core SDK for server-side integrations, where you interact with GBG GO from your own backend. The classic case is starting a journey: your credentials (client secret, API user password) must never be exposed on the client, so you start the journey server-side with the Core SDK and hand the resulting journey URL to the end-user device.

You can also use the Core SDK to build a fully custom UI — driving the journey entirely through the API and rendering every stage yourself. This is an advanced integration. If that’s your goal, read the recommendation below first.

The Core SDK is in beta. Pin to a specific version to avoid breaking changes between releases.

Bridge SDKs — embed a hosted journey

The Bridge SDKs let you easily embed one of our hosted journeys in your native app or website. They’re available for iOS, Android, and web today.

The hosted journey runs in a WebView (native) or iframe (web), and the Bridge SDK provides the communication layer between that journey and your host application. That layer gives you:

• Capability detection — the journey can discover which native features (camera, NFC, biometrics) your host supports and degrade gracefully when one isn’t available.
• Stage overrides — you can override individual stages of the hosted journey to provide your own UI, or a native implementation of a particular data collector, without rebuilding the whole journey.

If you want an advanced integration with your own UI, we recommend the Bridge SDK over a fully custom Core SDK build. You keep the hosted journey — with all its updates, orchestration, and compliance handling — and override only the specific stages or data collectors you want to own, rather than reimplementing everything from the API up.

At a glance

	Core SDK	Bridge SDKs
Runs on	Your server (Node.js, Bun, Deno)	The end-user device — iOS app, Android app, or web page
Talks to	The GBG GO API	A hosted GBG GO journey embedded in a WebView / iframe
Use it to	Authenticate, start journeys, submit data, check results, build a fully custom UI	Embed a hosted journey, detect capabilities, override stages with your own UI or native data collectors
Availability	Beta	iOS, Android, and Web available

SDK architecture

The diagram below shows where each SDK runs and how they hand off the journey URL and bridge messages between your server, the GBG GO platform, and the end-user device:

SDK	Type	Purpose	Runs on
Core SDK	Core	Type-safe client for the GBG GO API. Generate tokens, start journeys, manage tasks.	Your server (Node.js, Bun, Deno)
iOS Bridge SDK	Bridge	Native iOS host that loads the hosted journey in a WKWebView and fulfils capability requests.	Your iOS app
Android Bridge SDK	Bridge	Native Android host that loads the hosted journey and fulfils capability requests.	Your Android app
Web Bridge SDK	Bridge	Host-page SDK that embeds the hosted journey in an <iframe> and fulfils capability requests.	Your web app (React, Vue, Angular, Svelte, vanilla JS)

Which SDK do I need?

• Server-side integration only: use the Core SDK to authenticate, start journeys, submit data, and check results from your backend. This is sufficient if you’re building a server-driven flow or using the API directly.
• Embed a journey in a web app: use the Core SDK on your server to generate the journey URL, and the Web Bridge SDK on the host page to embed the hosted journey in an <iframe> and fulfil capability requests from your host code.
• Embed a journey in a native iOS app: use the Core SDK on your server to generate tokens and journey URLs, and the iOS Bridge SDK to load the hosted journey in a WKWebView and fulfil capability requests like camera capture, NFC, and biometrics.
• Embed a journey in a native Android app: same pattern as iOS — use the Core SDK server-side and the Android Bridge SDK as the native host.
• Build a fully custom UI: this is possible with the Core SDK alone, but for most advanced integrations we recommend a Bridge SDK so you can override just the stages you need while keeping the hosted journey.

Typical integration flow

1. Your server uses the Core SDK to authenticate and generate a journey URL with an end-user token.
2. Your app loads that URL in a WebView (iOS/Android) or iframe (web).
3. The hosted journey runs inside the WebView/iframe and automatically detects the host environment.
4. The host (iOS, Android, or Web Bridge SDK) receives capability requests and fulfils them using device or browser hardware.

The Bridge SDKs handle all messaging between the hosted journey and the host automatically. You only need to implement handlers for the capabilities your app supports (e.g., document camera, selfie camera, NFC).