Skip to main content

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.

GBG GO provides a set of SDKs that simplify integration. Each SDK serves a distinct role depending on where your code runs and what youโ€™re building.

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:
SDKPurposeRuns on
Core SDKType-safe client for the GBG GO API. Generate tokens, start journeys, manage tasks.Your server (Node.js, Bun, Deno)
iOS Bridge SDKNative iOS host that loads the web journey in a WKWebView and fulfils capability requests.Your iOS app
Android Bridge SDKNative Android host that loads the web journey and fulfils capability requests.Your Android app

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 or iframe: use the Core SDK on your server to generate tokens and journey URLs. The hosted web journey handles device capabilities automatically when embedded in a browser.
  • 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 web 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. (Coming soon)

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 web journey runs inside the WebView/iframe and automatically detects the host environment.
  4. The native host (iOS or Android Bridge SDK) receives capability requests and fulfils them using device hardware.
The Bridge SDKs handle all messaging between the web journey and the native host automatically. You only need to implement handlers for the capabilities your app supports (e.g., document camera, selfie camera, NFC).