Eventix activity platform
The ingest service collects what people do around an event into one activity stream: a page viewed, a newsletter sign-up, an order paid, a ticket scanned, a drink bought with a wristband, a mail opened. Each is an activity: a named thing that happened to a person at a time, with typed fields, its features. The CRM builds profiles, cohorts and journeys from that stream; the ingest service only collects, checks and stores.
Three kinds of sender feed it:
- Tracking calls are plain Segment messages (
page,track,identify). The browser SDK sends them; so does any Segment or RudderStack SDK pointed at this host. The service decides which activities a call becomes, so a site never needs a schema. - Activities are sent directly by senders that speak the catalogue's language: a backend, a partner, the shop. Every activity is in the catalogue, with its fields, who may send it and what it carries.
- Records are what Eventix's own systems have: a Weeztix order, a scan. A mapper in the service turns them into activities.
Where to start
| You want to | Read |
|---|---|
| Put tracking on a site | Install the SDK, then calls and consent |
| Send an activity from a backend | Getting started, then the activity you need and the envelope |
| Know what an activity may hold | Activities, identifiers, attributes, touch, geo, revenue |
| Know why something was quarantined | Validation |
| Call the API | API overview and the reference with live requests |
Every activity page and most API pages have a Try it form: paste a write key, point it at a service (the local stack by default) and send. Nothing but your own browser holds the key.
One activity, end to end
{
"activity_id": "0192f1a4-7c3e-7b21-9d0a-5e3f8c2a1b45",
"activity": "subscribed_newsletter",
"ts": "2026-10-17T20:00:00+02:00",
"identifiers": [{ "type": "email", "value": "Ana.de.Vries@example.com" }],
"features": { "email": "Ana.de.Vries@example.com", "list": "summer-fest-2027" }
}
The service finds the owner from the write key, checks the activity against the catalogue, normalises the email into a join key (and keeps it as typed for display), notes a claimed link between the email and the visitor's device, and stores one row in the stream with its features, one identifier row and the evidence. A second delivery of the same activity_id changes nothing.