Webhooks

WeZends leveringswebhooks er pr. besked: I sender webhook_url direkte med i send-requesten (eller pr. besked inde i en bulk-request), og statusopdateringer for den besked POSTes dertil, efterhånden som de sker. Til kontobrede platform-events findes desuden /v1/webhook-endpoints — se nedenfor.

{
  "to": "+4512345678",
  "channel": "sms",
  "message": "Din ordre er afsendt.",
  "webhook_url": "https://jeresapp.dk/hooks/wezend"
}

Payload og headers

Hver levering inkluderer:

• X-WeZend-Event — event-navnet
• X-WeZend-Timestamp — Unix ms-tidsstempel brugt i signaturen
• X-WeZend-Signature — HMAC-SHA256 af ${timestamp}.${JSON.stringify(payload)}, med webhook-signeringshemmeligheden fra Indstillinger → Webhook-hemmelighed

Hver levering indeholder også legacy-aliasser X-ZafeConnect-* af de samme tre headers, bevaret fra før rebrandingen, så eksisterende integrationer fortsat kan verificere. Værdierne er identiske med X-WeZend-*-headerne — verificér mod det præfiks, I allerede bruger.

Verificér 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));
}

Retries

Hvis jeres endpoint ikke svarer 2xx, genforsøges leveringen 3 gange — efter 30 sekunder, 5 minutter, og til sidst 30 minutter — og genforsøg overlever en genstart eller deploy (de er persistente, gemt i databasen, ikke en kø i hukommelsen). Svar hurtigt og behandl asynkront i stedet for at lave langsomt arbejde i selve request-handleren.

Platform-event webhooks

Ud over leveringswebhooks pr. besked kan I registrere kontobrede udgående endpoints: POST /v1/webhook-endpoints med { url, events } opretter et (administrér med GET/PATCH/DELETE, og POST /v1/webhook-endpoints/:id/test leverer et ping). Begge legitimationstyper virker — en API-nøgle eller et dashboard-JWT fra POST /v1/auth/login — så en serverside-integration kan tilmelde sig selv, uden at nogen åbner dashboardet. Hvert endpoint får sin egen whsec_...-signeringshemmelighed, som kun vises ved oprettelsen.

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øglen udstedt med en eksplicit scope-liste, kræver den write for at oprette, opdatere eller slette et endpoint. En nøgle med kun read kan liste endpoints, men får 403 insufficient_scope på mutationerne, med den manglende scope navngivet i svaret. Nøgler udstedt uden scope-liste beholder fuld adgang.

Der kan abonneres på ni event-typer i events. Et endpoint oprettet med et tomt events-array modtager dem alle.

Abonnér på contact.unsubscribed for at holde jeres egne samtykke-registreringer opdaterede. Før dette event fandtes, skubbede intet et opt-out ud af WeZend: hvis jeres system of record er noget andet — et CRM, en forhandlerportal, jeres egen database — var der ingen måde at få at vide, at en kontakt havde svaret STOP, og I ville blive ved med at behandle personen som tilmeldt. contact.bounced er et leveringssignal snarere end et eksplicit opt-out, så hold de to adskilt i jeres egne data.

Indgående leveringskvitteringer fra udbydere

Endpointsene /v1/webhooks/messente, /v1/webhooks/twilio, /v1/webhooks/vonage og /v1/webhooks/whatsapp er, hvordan opstrøms teleudbydere rapporterer levering tilbage til platformen — de er platform-interne og ikke noget I selv konfigurerer; de findes, så WeZend selv kan udfylde de statusser, I ser via webhook_url og beskedhistorik-API'et.