Sporing av hendelser

POST /v1/events/track er et offentlig, kun-skrivende endepunkt bygget for å kalles direkte fra kundens eget nettsted — det kan ta imot hendelser, men kan ikke lese noe tilbake, så det er trygt å kalle med bare en offentlig nøkkel, i motsetning til hoved-API-nøkkelen din.

Spor en enkelt hendelse

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 }
  }'

En enkelt hendelse returnerer 202 { "ok": true }.

Hendelser knyttes til en kontaktprofil via identifiers (email eller telefon) — en hendelse uten identifiers (eller en anonymous_id) aksepteres, men kan aldri knyttes til en kontaktprofil.

Batch av hendelser

{
  "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 } }
  ]
}

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

Origin-begrensning

Du kan sende nøkkelen som X-ZC-Key i stedet for i body-en. Hver offentlige nøkkel kan eventuelt begrenses til en tillatelsesliste med origins, slik at en lekket nøkkel bare kan brukes til å poste hendelser fra dine egne domener — en tom liste betyr alle origins. GET /v1/account/tracking-key returnerer den nøkkelen sammen med et klart-til-innliming-<script>-snutt, og PUT /v1/account/tracking-origins setter tillatelseslisten (f.eks. ["https://shop.eksempel.no"]).

Identifiser en navngitt kontakt

Event-tracking navngir ingen og krever derfor ingen signatur: den offentlige nøkkelen identifiserer kontoen din og ingenting annet. Alt som taler på en navngitt kontakts vegne, krever en — in-app-innboksen (POST /v1/inapp/feed, POST /v1/inapp/read) og det å knytte en push-enhet til en kontakt (POST /v1/push/subscribe med en email). Den offentlige nøkkelen ligger i sidekilden din og kan derfor aldri alene bevise at den besøkende er nettopp én bestemt av kontaktene dine.

De kallene tar en signatur som din egen server produserer — user_hash = HMAC-SHA256(lowercase(trim(email)), identitets-secreten din), 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)

Gjør adressen om til små bokstaver og trim den før hashen. Vi gjør det samme, så Anna@Firma.dk og anna@firma.dk verifiseres som samme kontakt — oppslaget bak signaturen er også case-insensitivt. Signerer du den rå strengen, får en bruker som skrev en stor bokstav en 403 som ser ut som vår feil.

Secreten hentes fra GET /v1/account/tracking-identity (dashbord: Innstillinger → Tracking) og er ikke den offentlige nøkkelen — hold den på serveren din. POST /v1/account/tracking-identity/rotate utsteder en ny og ugyldiggjør hver hash som allerede er beregnet, så rull ut den nye secreten før du roterer. Et kall som krever en signatur og kommer uten, avvises med 403 og identity_required: true. Push-registrering kan hoppe over det ved å utelate email — enheten er da anonym. Slår du kravet helt av (PUT /v1/account/tracking-identity med { "require_identity": false }), kan hvem som helst som leser sidekilden din hente hvilken som helst kontakts meldinger ved å oppgi adressen, så gjør det bare hvis du ikke har identifisert trafikk.

Hva skjer videre

Når hendelser kommer inn, beregnes beregnede traits på nytt og segmentmedlemskap oppdateres i sanntid — enhver journey som overvåker den triggeren eller det segmentet, kan utløses umiddelbart, uten en batchjobb involvert.