How Nexus fits together
The control plane, the data plane, the session spine and how your SDKs talk to them.
Nexus is one backend with two faces:
- the control plane — the console and its API, where people sign in, create projects, compose campaigns and read data; and
- the data plane — the partner API under
/partner/*, called by the SDKs (and by you) with an API key.
The session spine
Every signal that reaches the data plane carries some of three identifiers:
| Identifier | Meaning | Who sets it |
|---|---|---|
distinctId | Who — your id for the person | You, via identify |
sessionKey | Which journey — one app run / visit | The client SDK, per launch or tab |
deviceKey | Which install — stable across launches | The client SDK, persisted |
The backend resolves them into a subject (the person) and a session, and
attaches the event, log line, error, replay chunk, survey response or request
journey to both. That is why the console can show one person's timeline across
products, and why server-side telemetry joins the same story when you pass the
same distinctId. Details: Identity & sessions.
Products reuse each other
Products are built on each other rather than duplicating features:
- Telescope files exceptions in Errors and log entries in Logs, and attaches each journey to the session spine.
- In-app messages and Surveys are triggered by Events you already track.
- Remote Config can re-fetch live over Realtime.
- Live Activities are delivered over the Push credentials you configure once.
What the SDKs do for you
- Batching — events and logs are buffered and shipped in groups.
- Durability — the Flutter SDK keeps an on-device outbox, so telemetry survives offline periods and restarts.
- Context — the server SDKs keep the current person in ambient context
(
AsyncLocalStorage,contextvars,AsyncLocal<T>), so code deep in your service layer is attributed correctly without passing ids around. - Never crashing your app — a telemetry failure is logged, not thrown, unless you call an API whose result you asked for.