Skip to main content
Complete reference for every public type, method, and property in the GBGBridge Web SDK. Both the core package (@gbg/go-bridge-web) and the React adapter (@gbg/go-bridge-web-react) are covered. Packages: @gbg/go-bridge-web (core), @gbg/go-bridge-web-react (React 19 wrapper) Browsers: ES2020 / modern evergreen TypeScript: 5.x

Table of contents


Primary entry points

These are the types you interact with directly to wire the bridge into your app. Non-React hosts use BridgeHost directly; React hosts wrap it in BridgeHostProvider and consume via hooks.

BridgeHost

The central coordinator that manages message routing between an <iframe> and your host page.
Why it exists: BridgeHost decodes incoming messages from the journey iframe, validates origins, routes requests to registered handlers, tracks pending requests, and sends responses and events back to the iframe. It is the only object you must construct to use the SDK without React. Threading: JavaScript is single-threaded — there is no thread enforcement, but all calls happen on the main thread by definition.

Constructor

Constructs a host and immediately attaches it to the iframe. A built-in CapabilityQueryHandler is automatically registered for the "capability.query" action. Example:

Static properties

Constants exposed on the BridgeHost class itself, not on instances.
PROTOCOL_VERSION
The wire protocol version this SDK speaks. Exposed for integrator telemetry. The host warns and continues on inbound version mismatch rather than failing.

Properties


Methods

Imperative operations on a BridgeHost instance — attaching and detaching the iframe, registering handlers, sending events, and responding to requests.
attach
Re-attaches the host to a new iframe. Used internally by the constructor; rarely called directly. Preserves pendingRequests and receivedMessages buffers across the re-attach.
detach
Removes the window message listener and tears down the transport channel. Idempotent. After detach, inbound messages are no longer received and outbound sends are silently dropped. Call this when the iframe is removed from the page. BridgeHostProvider calls it automatically on unmount.
registerHandler
Registers a handler for a specific action ID. If a handler is already registered for the same action, it is replaced. This only attaches the handler — it does not declare the capability as supported. Use the capabilities constructor option or registerCustomCapability() for declaration.
getHandler
Returns the handler currently registered for the given action, or undefined. Used internally by useBridgeCapability to verify ownership before unregistering on unmount.
unregister
Removes the handler for the given action. Subsequent requests for that action will be added to pendingRequests and delegate.onUnhandledRequest will fire. Unregistering "capability.query" removes the SDK’s auto-registered handler — the SDK warns when this happens. Capability queries will stop receiving responses unless you register a replacement.
registerCustomCapability
Declares a capability AND optionally registers a handler in a single call. The capability appears in capability.query responses, and if handler is provided, requests for the matching action ID are routed to it. This is the closest web equivalent to iOS/Android’s “set handler on typed slot” pattern — both declaration and registration in one step.
sendEvent
Sends an event message to the journey iframe. Events are fire-and-forget — no response is expected. Generates a unique correlation ID in the format web-event-{uuid}.
respond
Sends a manual response to a pending request. Used to respond from outside a registered handler — for example, when handling a request asynchronously via delegate.onUnhandledRequest. If options.action is omitted, the SDK looks up the original request in pendingRequests and uses its action. On success, the request is removed from pendingRequests. The host enforces at-most-once delivery on terminal statuses (success, error, cancelled, unsupported). Subsequent calls with the same correlationId and a terminal status are dropped. acknowledged is interim and may precede a terminal status.
clearError
Resets lastError to null.

BridgeHostProvider

React provider that owns the BridgeHost lifecycle. Wrap your iframe-rendering subtree in this provider and use the hooks to interact with the bridge.
Why it exists: Bridges React’s component lifecycle with the imperative BridgeHost API. Holds the host in component state, sets up the underlying transport, exposes context to descendant hooks, and tears down on unmount. Lifecycle:
  1. Mounts with iframe={null} — no host yet.
  2. iframe element appears (via ref={setIframe} callback). Provider instantiates BridgeHost and snapshots allowedOrigins, hostVersion, and capabilities props.
  3. Re-renders that change props do not rebuild the host. Force a remount (key change) to apply runtime config updates.
  4. Unmount: cleanup calls host.detach() and clears the host from state.

Props

See BridgeHostProviderProps. Example:

React hooks

All hooks must be called inside a BridgeHostProvider. Outside the provider they no-op and log a one-time console.warn.

useBridgeHost

Returns the underlying BridgeHost instance, or null while the iframe hasn’t attached.
Why it exists: Lets descendants access imperative methods (sendEvent, registerCustomCapability, clearError, etc.) that don’t have dedicated hooks. Example:

useBridgeCapability

Registers a BridgeCapabilityHandler for the lifetime of the calling component.
The hook wraps handler in a stable proxy: identity never changes across renders, but the proxy delegates to the latest handler via a ref. An inline { handle: ... } object literal does not re-register on every render — only action changes (or a host swap) trigger re-registration. On unmount, the hook unregisters only if its own proxy is still the active handler. This prevents two components racing on the same action from accidentally removing each other’s installations. This only registers the handler. To declare the capability as supported, pass an entry in the provider’s capabilities prop or call host.registerCustomCapability(id, version, handler) directly. See Concepts → Declaring vs. Registering. Example:

useBridgeHostEvent

Subscribes to events emitted by the journey iframe with a specific action ID. The listener is invoked with the event’s data payload.
Listener identity affects the effect dependency array — wrap inline listeners in useCallback if you want a stable subscription across renders. Example:

useBridgeHostError

Subscribes to internal SDK errors — handler exceptions, send failures, delegate throws, and other errors routed via BridgeHost.fireError.
This subscribes to errors raised by the host itself. Errors returned to the journey via responder.error(...) are not surfaced here — they’re outbound responses, not internal failures.

Configuration types

The interfaces below configure BridgeHost and BridgeHostProvider at construction time. All are plain TypeScript interfaces — no classes or constructors.

BridgeHostOptions

Constructor argument for BridgeHost.

BridgeHostProviderProps

Props for BridgeHostProvider.

RespondOptions

Argument to BridgeHost.respond.

Capability types

Types and constants for declaring capabilities the host can fulfil. CapabilityInfo is per-capability metadata; CapabilityMap is the shape you pass to the constructor; CAPABILITY_IDS lists standard identifiers.

CapabilityInfo

Metadata about a single capability.

CapabilityMap

A map of capability IDs to CapabilityInfo.

CapabilityId

A type alias for the values in CAPABILITY_IDS. Useful when you want compile-time enforcement that a string is a standard capability identifier.

Environment

The platform reported in capability.query responses. Always "web" from this SDK.
The union is shared with the iframe-side SDK for type compatibility; host SDKs only ever emit their own platform’s value.

CAPABILITY_IDS

Standard capability identifiers, standardized across iOS, Android, and Web — the same string values appear in CAPABILITY_IDS on all three platforms, and on the iframe-side SDK. Use the constants rather than magic strings to avoid typos and to track value changes through TypeScript’s reference graph.

Message models

Every value that crosses the bridge is wrapped in a BridgeMessage envelope.

BridgeMessage

A structured envelope for all bridge communication.

BridgeMessageType


RequestPayload


RequestOptions


ResponsePayload


ResponseStatus


ResponseError


EventPayload


Actions

Standard action identifiers for events the journey emits and commands the host sends. Use the constants to avoid magic strings that drift.

BridgeActions

Known action identifiers used in events. Imported as BridgeActions and typed as BridgeAction.
See Messaging for the full bridge event catalogue with payload shapes.

Errors

A typed error class and enum for use in your own handler code when emitting structured errors — plus a helper to normalise unknown codes.

BridgeError

A typed error class for use in your own host code when emitting structured errors.
The SDK does not throw BridgeError internally — it’s a helper for your handler code. Catch it in your own error-handling and forward to responder.error({ code, message, recoverable }). Example:

BridgeErrorCode

The SDK additionally emits HANDLER_FAILURE (string literal, not in this enum) when a registered handler throws an uncaught exception and hasn’t already responded.

toBridgeErrorCode

Validates that a string matches a known BridgeErrorCode, falling back to INTERNAL_ERROR otherwise. Useful when receiving error codes from external sources (e.g., parsing a response from the iframe). Returns: A BridgeErrorCode enum value.

Interfaces

Contracts your host code implements — one for capability handlers, one for observing bridge activity.

BridgeCapabilityHandler

The contract for objects that handle bridge request actions.
A handler may be synchronous or asynchronous. Returning a Promise that rejects has the same effect as throwing synchronously — the host’s exception handler kicks in. If the handler throws or its returned Promise rejects, and the responder has not been called, the host automatically sends an error response with code: "HANDLER_FAILURE" and recoverable: false so the journey is never left waiting. Example:

BridgeHostDelegate

An observer interface for monitoring bridge activity. All methods are optional.
Delegate method exceptions are caught: a throw from onMessage or onUnhandledRequest is routed to onError. A throw from onError is logged via console.warn and swallowed (preventing recursion).

Classes

Concrete classes exposed by the SDK. Integrators use them but don’t instantiate them directly — the host creates them and hands them to your handlers.

BridgeResponder

Handed to handlers as the second argument. Used to send a response to the originating request.
Why it exists: Decouples the handler from the host. Handlers don’t need to know about postMessage or correlation IDs — they just call a terminal method. You don’t instantiate BridgeResponder directly. The host creates one per inbound request and passes it to the handler.

Properties

State exposed on the responder instance.
hasResponded
true after a terminal method (success, error, cancelled, unsupported) has been called. acknowledge does not set this to true.

Methods

One interim method (acknowledge) and four terminal methods — call exactly one terminal per request.
acknowledge
Sends an interim acknowledged response to signal “I got it, working on it”. Chainable. At-most-once on the wire — no-op after a prior acknowledge or after a terminal status. Use this for long-running operations to confirm receipt before the terminal response. The journey-side SDK uses acknowledgment to distinguish “host received but slow” from “host never received” timeout cases. Returns: The responder itself, for chaining.
success
Sends a terminal success response. Subsequent calls on this responder are no-ops.
error
Sends a terminal error response with the given error details.
cancelled
Sends a terminal cancelled response. When reason is provided, the response includes an error payload with code: "CANCELLED" and recoverable: true.
unsupported
Sends a terminal unsupported response. When reason is provided, the response includes an error payload with code: "UNSUPPORTED" and recoverable: false.

Built-in handlers

Handlers the SDK auto-registers for you. Documented here so you know what to look for in capability.query responses and how to override them if needed.

CapabilityQueryHandler

The handler for "capability.query" requests. Automatically registered by BridgeHost — you do not register this yourself.
Why it exists: Capability negotiation is a fundamental part of the protocol. The handler is auto-registered so journeys can always discover capabilities without integrator setup.

Response format

The handler is constructed automatically by BridgeHost with a provider that returns the current buildEffectiveCapabilities() map (capabilities option merged with registerCustomCapability entries). Calling unregister('capability.query') removes it and stops automatic responses — the SDK warns when this happens.

React context

These are the low-level context types exported from @gbg/go-bridge-web-react. Most integrators do not interact with them directly — the hooks wrap them. Exposed for advanced cases (custom providers, testing).

BridgeHostContext

The React context that BridgeHostProvider populates. The default value (used outside any provider) is a marker that lets hooks detect missing providers and issue a one-time warning.

BridgeHostContextValue


BridgeHostEventListener

Listener signature for event subscriptions. Receives the event’s data payload — the action is implicit (it’s the action you subscribed with).

BridgeHostErrorListener

Listener signature for error subscriptions.

Next steps

  • Concepts — Architecture and design rationale behind these types.
  • Embedding — Integration patterns by framework.
  • Messaging — Event catalogue and request/response semantics.
  • Capability Handling — Declaring, registering, and dynamic capabilities.