POST /v1/track with plain HTTP, and shows the SDK equivalent at the end.
You need your org_ API key for step 1; after that, everything runs with the
publishable key.
1. Issue a tracking key
Tracking keys are publishable - they ship in your client code like an analytics measurement id. Their abuse controls are an origin allowlist and per-key rate limiting, not secrecy. Issue one with your server-side API key:201 Created:
GET /v1/engagement/keys lists your keys; DELETE /v1/engagement/keys/{id}
revokes one.
2. Send events over plain HTTP
POST /v1/track takes the tracking key as ?key= (or a key field in the
body) - no Authorization header. Events must identify a known member,
by the external_id you gave them at creation or by platform user_id.
Batch up to 20 events per request:
202 Accepted, with a per-event outcome:
fetch - the endpoint is CORS-enabled:
event_idis your retry safety. Send a client-generated UUID per event and the server dedupes on it - a retried request reportsduplicatefor events that already landed, and nothing double-counts.- Tags are trimmed and lowercased, must match
^[a-z0-9][a-z0-9_.:-]{0,63}$, max 10 per event. Tags drive the member’s affinity counters - see Events. - Unknown members are rejected, not stored. An event for an id that
doesn’t resolve to a member of your org comes back
{ "status": "rejected", "reason": … }in the 202 envelope. - A single event can also be posted without the
eventswrapper (beacon shorthand):{ "key": "ek_live_…", "member_external_id": "…", "tags": […] }.
3. The SDK equivalent
The engagement SDK wraps this endpoint with batching, auto-flush, retry with dedupe, andsendBeacon drain on page hide: