Webhooks

WeZends leveranswebhooks är per meddelande: du skickar med webhook_url direkt i sändningsanropet (eller per meddelande inuti en bulk-request), och statusuppdateringar för det meddelandet POST:as dit allteftersom de sker. För kontoövergripande plattformshändelser finns dessutom /v1/webhook-endpoints — se nedan.

{
  "to": "+4512345678",
  "channel": "sms",
  "message": "Din order har skickats.",
  "webhook_url": "https://dinapp.se/hooks/wezend"
}

Payload och headers

Varje leverans innehåller:

• X-WeZend-Event — händelsens namn
• X-WeZend-Timestamp — Unix ms-tidsstämpel som används i signaturen
• X-WeZend-Signature — HMAC-SHA256 av ${timestamp}.${JSON.stringify(payload)}, med webhook-signeringshemligheten från Inställningar → Webhook-hemlighet

Varje leverans innehåller också legacy-aliasen X-ZafeConnect-* för samma tre headers, kvar sedan före ombrandningen så att befintliga integrationer fortsätter att verifiera. Värdena är identiska med X-WeZend-*-headers — verifiera mot det prefix du redan använder.

Verifiera 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));
}

Omförsök

Om din endpoint inte svarar 2xx görs 3 nya leveransförsök — efter 30 sekunder, 5 minuter och slutligen 30 minuter — och omförsöken överlever en omstart eller driftsättning (de är beständiga och lagras i databasen, inte i en kö i minnet). Svara snabbt och behandla asynkront i stället för att göra långsamt arbete i själva request-hanteraren.

Plattformshändelse-webhooks

Utöver leveranswebhooks per meddelande kan du registrera kontoövergripande utgående endpoints: POST /v1/webhook-endpoints med { url, events } skapar en (hantera med GET/PATCH/DELETE, och POST /v1/webhook-endpoints/:id/test levererar en ping). Båda typerna av inloggningsuppgifter fungerar — en API-nyckel eller en dashboard-JWT från POST /v1/auth/login — så en integration på serversidan kan registrera sig själv utan att någon öppnar dashboarden. Varje endpoint får sin egen whsec_...-signeringshemlighet som bara visas vid skapandet.

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

Om nyckeln utfärdats med en explicit scope-lista krävs write för att skapa, uppdatera eller ta bort en endpoint. En nyckel med bara read kan lista endpoints men får 403 insufficient_scope på mutationerna, med den saknade scopen namngiven i svaret. Nycklar som utfärdats utan scope-lista behåller full åtkomst.

Nio händelsetyper kan prenumereras på i events. En endpoint som registreras med en tom events-array tar emot alla.

Prenumerera på contact.unsubscribed för att hålla dina egna samtyckesregister i synk. Innan händelsen fanns skickade ingenting ett opt-out ut ur WeZend: om ditt system of record är något annat — ett CRM, en återförsäljarportal, din egen databas — fanns det inget sätt att få veta att en kontakt hade svarat STOP, och du skulle fortsätta behandla personen som prenumerant. contact.bounced är ett leveranssignal snarare än ett uttryckligt opt-out, så håll de två åtskilda i dina egna data.

Inkommande leveranskvitton från leverantörer

Endpointerna /v1/webhooks/messente, /v1/webhooks/twilio, /v1/webhooks/vonage och /v1/webhooks/whatsapp är hur uppströms operatörer rapporterar leverans tillbaka till plattformen — de är plattformsinterna och inget du konfigurerar; de finns för att WeZend själv ska kunna fylla i de statusar du ser via webhook_url och meddelandehistorik-API:et.