Getting started

1. A write key

Everything is sent with a write key. Its class decides what it may send (write keys):

Class	Looks like	For
browser	`pk_live_…`	A website or app. Public by design.
server	`sk_live_…`	An organiser's backend or a partner. Secret.
platform	`ik_…`	Eventix's own systems, for any organiser. Never issued to organisers.

Keys come from the Eventix dashboard.

A key is sent as HTTP Basic authentication with the secret as the user name and an empty password. A browser key may travel in the body instead (writeKey), because a beacon cannot set headers.

curl -u 'sk_live_…:' https://api.evtx.nl/v1/activities -d '…'

2. A first tracking call

Sites send Segment messages to POST /v1/batch. The service completes and stores every call and decides what it becomes (tracking calls):

curl -s https://api.evtx.nl/v1/batch \
  -H 'Content-Type: application/json' \
  -d '{"writeKey":"pk_live_…","debug":true,"batch":[
        {"type":"page","anonymousId":"evx_web_8f21c0","context":{"page":{"url":"https://summerfest.nl/tickets","title":"Tickets"}}}
      ]}'

With debug, the answer says for each call which activities it became and the processor's verdict on each. The page call becomes a viewed_page.

3. A first activity

Senders that know the catalogue send activities to POST /v1/activities (sending activities). Each activity page shows a full example; here is a newsletter sign-up from a backend:

curl -s -u 'sk_live_…:' https://api.evtx.nl/v1/activities \
  -H 'Content-Type: application/json' \
  -d '{"debug":true,"batch":[{
        "activity_id":"0192f1a4-7c3e-7b21-9d0a-5e3f8c2a1b45",
        "activity":"subscribed_newsletter",
        "ts":"2026-10-17T20:00:00+02:00",
        "identifiers":[{"type":"email","value":"ana@example.com"}],
        "features":{"email":"ana@example.com","list":"summer-fest-2027"}
      }]}'

{"accepted":1,"trace_id":"…","verdicts":[{"activity_id":"0192f1a4-…","activity":"subscribed_newsletter","verdict":"accepted","schema_version":2}]}

A 202 means the batch is durably stored. What happens next is decided after the acknowledgement: an activity that is well-formed enough to attribute but fails validation is quarantined with a reason, never refused, so a sender never retries something that fails every time (validation).

4. Idempotency

activity_id is the idempotency key: send the same activity twice, and the second copy is dropped. Derive it from what the activity is (an order id, a ticket id and the activity name) and a retry can never double-count. For tracking calls the SDK's messageId plays that role.

5. Owners

Every activity belongs to one organiser, the owner. A browser or server key belongs to an owner, so nothing needs saying. A platform key serves every organiser, so each activity names its owner in owner_ref (own:…, evx:…); so does a group key, one key for several organisers.

Try it from these pages

Every activity page has a form that sends the example to a service of your choice with a key you paste. Both stay in your browser. The local stack allows the site's origin (ADD_CORS=true); a production service has to list the origin it should accept.

1. A write key​

2. A first tracking call​

3. A first activity​

4. Idempotency​

5. Owners​

Try it from these pages​