Write keys
A write key says who is sending and, through its class, what the sender may send. The same keys serve tracking calls and activities.
| Class | Format | Where it lives | What it may send |
|---|---|---|---|
| Browser | pk_live_… | In page source. Public by design: anyone can read it and send with it. | Browser-class activities only (viewed_page, started_session, the basket activities from started_basket to placed_basket, identified, submitted_form, subscribed_newsletter, and custom activities an organiser opens to it). No revenue. Identity evidence only as a claim. No geo block. |
| Server | sk_live_… | The organiser's backend or a partner (cashless, mail). Secret. | Server-class activities, including revenue-bearing ones it is scoped to, and the geo block. |
| Platform | ik_… | Eventix's own systems. One key covers all organisers; never issued to organisers. | The activities its system produces, for any organiser, with the owner named on each activity (owner_ref). Supplier webhooks. |
| Group | a browser or server key for several organisers | A venue site selling for six promoters. | As its class, with owner_ref on every activity naming a member of the group. |
Each activity's page says which classes may send it; the catalogue refuses the others with key_class_not_allowed, which is a 400 for the whole batch when the activity is sent directly.
Why a leaked browser key is harmless
A browser key is an identifier, not a credential. What makes a leak harmless is the class restriction, not secrecy: it cannot send a completed_order, cannot set revenue, cannot place a person with a geo block, and any identity edge it creates from an email typed into a form is only claimed: stored, but not allowed to merge two people until something verified confirms it. The worst case is fake page views.
Sending the key
HTTP Basic authentication, the secret as the user name, an empty password:
Authorization: Basic base64("sk_live_…:")
A browser key may also travel in the body as writeKey on /v1/batch and /v1/activities, because a beacon cannot set headers. Segment and RudderStack SDKs do this by themselves.
Modes and limits
A key is in enforce mode (non-conforming events are quarantined) or, during onboarding, in observe mode (stored but flagged and kept out of the CRM's views; it expires). Each key has a rate limit; above it the service answers 429 with Retry-After. The body limit is 500 KB per request.
Creating, rotating and revoking keys
Keys are managed from the CRM's Settings page, per company, by a workspace admin. A new browser key starts in observe mode for 14 days, a server key in enforce; the mode can be switched at any time, and switching back to observe starts a new 14-day window. The secret is shown once, when the key is created or rotated: a rotation keeps the key id, so nothing in history changes, and the previous secret keeps working for 7 days while the site or backend moves to the new one. A revoked key stops at once and stays in the list as revoked; it is never deleted, because past events point at it.