Webhooks

WeZends leveringswebhooks er per melding: du sender med webhook_url direkte i sendeforespørselen (eller per melding inne i en bulk-request), og statusoppdateringer for den meldingen POST-es dit etter hvert som de skjer. For kontoomfattende plattformhendelser finnes i tillegg /v1/webhook-endpoints — se nedenfor.

{
  "to": "+4512345678",
  "channel": "sms",
  "message": "Bestillingen din er sendt.",
  "webhook_url": "https://appendin.no/hooks/wezend"
}

Payload og headere

Hver levering inkluderer:

• X-WeZend-Event — hendelsesnavnet
• X-WeZend-Timestamp — Unix ms-tidsstempel brukt i signaturen
• X-WeZend-Signature — HMAC-SHA256 av ${timestamp}.${JSON.stringify(payload)}, med webhook-signeringshemmeligheten fra Innstillinger → Webhook-hemmelighet

Hver levering inneholder også legacy-aliasene X-ZafeConnect-* for de samme tre headerne, beholdt fra før rebrandingen slik at eksisterende integrasjoner fortsetter å verifisere. Verdiene er identiske med X-WeZend-*-headerne — verifiser mot det prefikset du allerede bruker.

Verifiser signaturen

const crypto = require("crypto");

function verify(rawBody, timestamp, signature, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(`${timestamp}.${rawBody}`)
    .digest("hex");
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
}

Nye forsøk

Hvis endepunktet ditt ikke svarer 2xx, gjøres leveringen på nytt 3 ganger — etter 30 sekunder, 5 minutter og til slutt 30 minutter — og forsøkene overlever en omstart eller deploy (de er varige og lagres i databasen, ikke i en kø i minnet). Svar raskt og behandle asynkront i stedet for å gjøre tungt arbeid i selve request-håndtereren.

Plattformhendelse-webhooks

I tillegg til leveringswebhooks per melding kan du registrere kontoomfattende utgående endepunkter: POST /v1/webhook-endpoints med { url, events } oppretter ett (administrer med GET/PATCH/DELETE, og POST /v1/webhook-endpoints/:id/test leverer en ping). Begge legitimasjonstypene virker — en API-nøkkel eller et dashbord-JWT fra POST /v1/auth/login — slik at en integrasjon på serversiden kan melde seg på selv, uten at noen åpner dashbordet. Hvert endepunkt får sin egen whsec_...-signeringshemmelighet som bare vises ved opprettelsen.

curl -X POST https://api.wezend.com/v1/webhook-endpoints \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://example.com/hooks/wezend", "events": ["contact.unsubscribed"] }'

Er nøkkelen utstedt med en eksplisitt scope-liste, kreves write for å opprette, oppdatere eller slette et endepunkt. En nøkkel med bare read kan liste endepunkter, men får 403 insufficient_scope på mutasjonene, med den manglende scopen navngitt i svaret. Nøkler utstedt uten scope-liste beholder full tilgang.

Ni hendelsestyper kan abonneres på i events. Et endepunkt som registreres med en tom events-array mottar alle.

Abonner på contact.unsubscribed for å holde dine egne samtykkeregistreringer i synk. Før hendelsen fantes, dyttet ingenting et opt-out ut av WeZend: hvis system of record hos deg er noe annet — et CRM, en forhandlerportal, din egen database — fantes det ingen måte å få vite at en kontakt hadde svart STOP, og du ville fortsette å behandle personen som påmeldt. contact.bounced er et leveringssignal snarere enn et eksplisitt opt-out, så hold de to atskilt i dine egne data.

Innkommende leveringskvitteringer fra leverandører

Endepunktene /v1/webhooks/messente, /v1/webhooks/twilio, /v1/webhooks/vonage og /v1/webhooks/whatsapp er måten oppstrøms operatører rapporterer levering tilbake til plattformen — de er plattforminterne og ikke noe du konfigurerer selv; de finnes for at WeZend selv skal kunne fylle inn statusene du ser via webhook_url og meldingshistorikk-API-et.