SDKs overview

Sankofa speaks to your code through SDKs. Every official SDK calls into the same engine using the event ingestion and (where applicable) the decision handshake protocols.

Pick the platform you want and follow its dedicated guide.

The asymmetric matrix

The matrix splits into three groups:

1. Web — multi-package

   Seven small packages. Install only what you use. Tree-shakeable. Every product (Catch, Switch, Config, Pulse, Replay, React) is an optional plugin to @sankofa/browser.

2. Mobile — single SDK

   Flutter, React Native, iOS, and Android each ship a single SDK that bundles every supported client product (Analytics, Catch, Switch, Config, Pulse, Replay). Of these, only React Native ships Deploy/OTA at the SDK level today.

3. Server — Catch-focused

   Node, Go, Java, and Python SDKs focus on Catch (error tracking) plus distributed tracing. Server-side flag and config evaluation is not built into these SDKs — instead they accept optional readFlagSnapshot / readConfigSnapshot callbacks so captured error events can include flag context.

Feature × platform matrix

✓ = full support; ◐ = partial; — = not shipped at the SDK level.

A few specific notes from this matrix:

• A/B testing is built into Switch + Config. Switch flag variants and Config A/B item experiments share the same targeting engine — there's no separate "A/B Switch" product or SDK module.
• Deploy / OTA is React-Native only at the SDK layer. Native iOS / Android / Flutter SDKs do not export a SankofaDeploy class today. Pure-native apps use Switch for feature gating + the platform's standard staged rollouts.
• Pulse is mobile + web only. Server SDKs don't render UI, so they don't ship Pulse.
• Server SDKs are Catch-focused. They expose error capture, breadcrumbs, transactions, and profiling. They do not expose Sankofa.flags.get(...) / Sankofa.config.get(...) calls — instead, they accept callbacks (readFlagSnapshot, readConfigSnapshot) that you wire to your own flag system, so error events can include flag context.

Where they're hosted

All SDKs are open source under permissive licenses. The Sankofa platform — engine, dashboard, admin — is proprietary; only the SDKs are open.

Common ground across all SDKs

Every SDK ships a consistent API for the basics:

1. Initialize once, as early as possible

   init (or initialize) takes an apiKey and an endpoint. Subsequent calls are no-ops. Initialize before you fire any tracking calls.

2. Capture errors with `captureException`

   On the server SDKs and Web's @sankofa/catch, this is the primary product call. On mobile, it's also available via SankofaCatch.

3. Track events (where supported)

   Web and mobile SDKs expose track(eventName, properties?). Server SDKs are Catch-focused — they capture errors, transactions, and breadcrumbs, but don't expose a generic track(...).

4. Flush before exit

   Every SDK exposes flush() (or equivalent) — drains the queue. Call it from your shutdown handler in long-running processes.

Common ground across all client SDKs (web + mobile)

Client SDKs (web, Flutter, RN, iOS, Android) share three more things that server SDKs do not:

• Offline-first event queue — events are durable across app restarts and survive network failures.
• Decision handshake at session start — one snapshot per session covers Switch flags + variants, Config items + A/B experiments, and Pulse triggers.
• Default property collection — geo, OS, device, browser, app version, session — added automatically.

Server SDKs use an in-memory queue, no decision handshake, and a smaller default-property set focused on the runtime + request context.

What's next