Track from React Native

This tutorial gets @binoban/react-native sending its first identify and track events from a React Native app. @binoban/react-native is a TurboModule bridge over the same Native SDK outputs — Android via io.binoban.sdk:sdk-android, iOS via the binoban XCFramework. It is not an independent implementation: every call crosses the bridge into native code, so its behavior — identity, batching, the apiHost requirement — matches the native platforms.

Before you begin

You need:

• A React Native app on the New Architecture (TurboModules) — on the old architecture the native module resolves to null and the SDK is an inert no-op.
• react >= 18, react-native >= 0.71; Android minSdk 24+; iOS per React Native's min_ios_version_supported.
• Your Binoban source credentials — apiKey and sourceIdentifier — per platform, and your apiHost, all from your Binoban workspace. (New to credentials? See the Quick Start.)

apiHost is required

Like the underlying Native SDK, apiHost has no default ('') and is a required top-level field on createClient's config. A missing/blank apiHost, or missing per-platform credentials, leaves the client inert: it logs a warning and sends nothing — there is no cloud fallback.

Step 1 — Install the package

npm install @binoban/react-native

Ships as 1.0.0. If npm install can't resolve the package, check the compatibility matrix — publish status is still being finalized.

Step 2 — Initialize the bridge

createClient takes per-platform credentials plus a top-level apiHost:

import { createClient, BinobanProvider, useBinoban } from '@binoban/react-native';

const client = createClient({
  credentials: {
    android: { apiKey: 'YOUR_ANDROID_KEY', sourceIdentifier: 'YOUR_ANDROID_SOURCE' },
    iOS:     { apiKey: 'YOUR_IOS_KEY',     sourceIdentifier: 'YOUR_IOS_SOURCE' },
  },
  apiHost: 'YOUR_API_HOST',
});

Wrap your app in the provider once, near the root:

<BinobanProvider client={client}>
  <App />
</BinobanProvider>

Then read the client from any component with the hook:

const { track, identify, flush } = useBinoban();

createClient picks the platform's credentials at runtime via Platform.OS — you don't branch on platform yourself. The SDK generates and persists an anonymous ID at this point, so it can attribute activity even before a user signs in.

Step 3 — Identify the current user

When the user signs in, call identify with your own user ID and any traits:

identify('user_123', { name: 'Jane Doe', email: 'jane@example.com' });

Step 4 — Track an action

track records something the user did — its first argument is the event name, its second a properties object:

track('signed_up', { plan: 'Enterprise' });

Step 5 — Flush and verify

The bridge batches events and sends them automatically (every flushAt events or flushInterval seconds — 20 events / 30s by default). To send immediately during testing, flush by hand:

flush();

Then confirm delivery: watch your app's network traffic for a POST to …/api/tracker/sdk/android (on Android) or …/api/tracker/sdk/ios (on iOS) returning 200 — the bridge crosses into whichever native platform is running, so the request lands on that platform's fixed SDK endpoint, not a React-Native-specific one, and (unlike the Tracking REST API) carries no {sourceIdentifier} path segment. A 401 means the apiKey is wrong; a connection failure points at the apiHost. As with the native platforms, a 200 means Binoban accepted the event — it then resolves into your source's profiles in the workspace.

What you've done

You installed the bridge, initialized it with per-platform credentials and the required apiHost, identified a user, tracked an action, and verified delivery — the full React Native tracking loop.

Next steps

• See a working example → binoban-example-react-native, a minimal app wiring up everything above, plus opt-in push and a safety harness for the bridge's never-throw contract. See Example Apps for all three platforms.
• Full method surface and configuration → the React Native SDK reference — every method signature, the configuration options table, and identity reads (anonymousId, userId, deviceId).
• Android or iOS instead? The native platforms this bridge wraps — Android · iOS.
• Model identity well across platforms → Identity strategy, including deviceId and multi-device behavior.
• Before production → the Go-live checklist.