Skip to main content
context is optional environment metadata about where and how an event was produced. It is not identity (userId, traits) and not business event data (event, properties). SDKs populate most of this automatically. When calling the HTTP API from your server, send only what you know (often just ip and/or library).

When to send it

  • From SDKs: Usually leave it alone — the SDK attaches context on every call.
  • From your backend: Include useful server-known fields such as ip, library, and optionally app.
  • Optional: Events are accepted without context. Richer context improves platform detection, segmentation, and debugging.

Example

Omit any field you do not have. Nested objects may be partial.

Field reference

Top-level

library

Which SDK or integration produced the event.

app

device

os

screen

Display metrics (typically from mobile / browser SDKs).

page

Mostly used by the browser SDK for page views and tracks.

campaign

UTM / campaign attribution (typically browser).

How Zixflow uses context

Platform detection (devices / push) prefers, in order:
  1. context.device.type (ios / android / web)
  2. context.os.name
  3. context.library.name (browser libraries → web)
  4. Presence of userAgentweb
Context also supports segments (device type, OS, app version), locale/timezone-aware messaging, and debugging which client produced an event.

Server-side example

Minimal context from a backend track call:

What not to put in context

  • Business event details → use properties (track / screen / page)
  • Durable user profile fields → use identify traits
  • Required identity → use userId and/or anonymousId

Applies to

context can be sent on: