Spåra händelser

POST /v1/events/track är en publik, skrivskyddad endpoint byggd för att anropas direkt från kundens egen webbplats — den kan ta emot events men kan inte läsa tillbaka något, så den är säker att anropa med enbart en publik nyckel, till skillnad från din huvudsakliga API-nyckel.

Spåra ett enskilt event

curl -X POST https://api.wezend.com/v1/events/track \
  -H "Content-Type: application/json" \
  -d '{
    "public_key": "wz_pk_...",
    "event": "product_viewed",
    "identifiers": { "email": "anna@example.com" },
    "properties": { "sku": "DK-1180", "price": 499 }
  }'

Ett enskilt event returnerar 202 { "ok": true }.

Events knyts till en kontaktprofil via identifiers (email eller telefon) — ett event utan identifiers (eller ett anonymous_id) accepteras men kan aldrig kopplas till en kontaktprofil.

Batcha events

{
  "public_key": "wz_pk_...",
  "events": [
    { "event": "product_viewed", "identifiers": { "email": "anna@example.com" }, "properties": { "sku": "DK-1180" } },
    { "event": "add_to_cart", "identifiers": { "email": "anna@example.com" }, "properties": { "sku": "DK-1180", "qty": 1 } }
  ]
}

returnerar 202 { "accepted": 2, "rejected": 0 }.

Origin-begränsning

Du kan skicka nyckeln som X-ZC-Key i stället för i bodyn. Varje publik nyckel kan valfritt begränsas till en tillåtelselista med origins, så att en läckt nyckel bara kan användas för att posta events från dina egna domäner — en tom lista betyder alla origins. GET /v1/account/tracking-key returnerar den nyckeln tillsammans med ett färdigt <script>-snutt, och PUT /v1/account/tracking-origins sätter tillåtelselistan (t.ex. ["https://shop.exempel.se"]).

Identifiera en namngiven kontakt

Event-tracking namnger ingen och kräver därför ingen signatur: den publika nyckeln identifierar ditt konto och inget annat. Allt som talar för en namngiven kontakt kräver en — in-app-inkorgen (POST /v1/inapp/feed, POST /v1/inapp/read) och att koppla en push-enhet till en kontakt (POST /v1/push/subscribe med en email). Den publika nyckeln ligger i din sidkälla och kan därför aldrig i sig bevisa att besökaren är just en av dina kontakter.

De anropen tar en signatur som din egen server producerar — user_hash = HMAC-SHA256(lowercase(trim(email)), din identitets-secret), hex:

// your backend, when rendering the page — never in browser code
const crypto = require("crypto");
const email = user.email.trim().toLowerCase();
const userHash = crypto.createHmac("sha256", process.env.WEZEND_IDENTITY_SECRET)
                       .update(email).digest("hex");
// hand userHash to the page next to the email, then: wezend.identify(email, userHash)

Gör adressen till gemener och trimma den före hashen. Vi gör detsamma, så Anna@Firma.dk och anna@firma.dk verifieras som samma kontakt — uppslaget bakom signaturen är också skiftlägesokänsligt. Signerar du den råa strängen får en användare som skrev en versal en 403 som ser ut som vårt fel.

Secreten hämtas från GET /v1/account/tracking-identity (dashboard: Inställningar → Tracking) och är inte den publika nyckeln — håll den på din server. POST /v1/account/tracking-identity/rotate utfärdar en ny och ogiltigförklarar varje hash som redan beräknats, så driftsätt den nya secreten innan du roterar. Ett anrop som kräver en signatur och kommer utan avvisas med 403 och identity_required: true. Push-registrering kan hoppa över det genom att utesluta email — enheten blir då anonym. Stänger du av kravet helt (PUT /v1/account/tracking-identity med { "require_identity": false }) kan vem som helst som läser din sidkälla hämta vilken kontakts meddelanden som helst genom att ange adressen, så gör det bara om du inte har identifierad trafik.

Vad händer sedan

När events landar räknas beräknade traits om och segmentmedlemskap uppdateras i realtid — varje journey som bevakar den triggern eller det segmentet kan utlösas omedelbart, utan något batch-jobb inblandat.