> ## 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.

# 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

<Columns>
  <Card title="Core SDK" icon="server" href="/docs/go-v2/developer-integration/sdks/core-sdk">
    A generated, type-safe client for the GBG GO API. Runs on your **server** to
    authenticate, start journeys, and exchange data.
  </Card>

  <Card title="Bridge SDKs" icon="mobile" href="/docs/go-v2/developer-integration/sdks/ios-sdk">
    Native and web hosts that **embed a hosted GBG GO journey** in your app or
    website and let it reach device capabilities.
  </Card>
</Columns>

### 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.

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

### 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.

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

## 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:

```mermaid theme={null}
graph LR
    subgraph Server["Your server"]
        A["Core SDK<br/>@gbg/go-core"]
    end
    subgraph GBG["GBG GO"]
        API["GBG GO API"]
        B["Hosted journey"]
    end
    subgraph Device["End user device"]
        D["iOS Bridge SDK"]
        E["Android Bridge SDK"]
        F["Web Bridge SDK"]
    end
    A -->|"Start journey"| API
    API -->|"Return journey URL"| A
    A -->|"Pass journey URL"| D
    A -->|"Pass journey URL"| E
    A -->|"Pass journey URL"| F
    API <-->|"Journey data"| B
    D <-->|"Bridge messaging"| B
    E <-->|"Bridge messaging"| B
    F <-->|"Bridge messaging"| B
```

| SDK                                                                      | Type   | Purpose                                                                                         | Runs on                                                |
| ------------------------------------------------------------------------ | ------ | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| [Core SDK](/docs/go-v2/developer-integration/sdks/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](/docs/go-v2/developer-integration/sdks/ios-sdk)         | Bridge | Native iOS host that loads the hosted journey in a `WKWebView` and fulfils capability requests. | Your iOS app                                           |
| [Android Bridge SDK](/docs/go-v2/developer-integration/sdks/android-sdk) | Bridge | Native Android host that loads the hosted journey and fulfils capability requests.              | Your Android app                                       |
| [Web Bridge SDK](/docs/go-v2/developer-integration/sdks/web-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](/docs/go-v2/developer-integration/sdks/web-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.

<Note>
  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).
</Note>