Afsendelse af beskeder

POST /v1/messages/send er det ene endpoint til alle kanaler.

Påkrævede felter

to, channel (én af sms, rcs, whatsapp, email, voice) og message er påkrævet — eller send et channels-array i stedet for channel/fallback (se nedenfor).

Kanal-fallback

Angiv en ordnet fallback-liste, eller det nyere channels-array med primær kanal først:

{
  "to": "+4512345678",
  "channels": ["whatsapp", "sms"],
  "message": "Din ordre er afsendt."
}

Hvis WhatsApp-levering fejler, forsøger platformen automatisk igen via SMS — uden et separat API-kald.

Kanal-specifikke felter

• Email: sæt subject, og htmlmessage (eller det ældre alias html) til HTML-body'en. message er plain-text-fallbacken.
• WhatsApp: send et whatsapp-objekt, fx { "template": "order_shipped" }, til skabelonbeskeder uden for 24-timers sessionsvinduet.
• Voice: send et voice-objekt (fx { "voice": "female", "language": "da-DK" }) til TTS-parametre.
• Afsender-ID: sender skal være et afsender-ID godkendt i Indstillinger → Afsender-ID'er til SMS/RCS — medmindre jeres konto har allow_unverified_sender aktiveret til systemintegrationer.

Reply-To, afsendernavn og egne headers

Tre valgfrie email-felter:

• reply_to — hvor svar skal havne. Enten en ren adresse (support@jeresfirma.dk) eller formen med visningsnavn (Support <support@jeresfirma.dk>); adressedelen valideres som en email. Feltet er bevidst ikke domænelåst — Reply-To er ikke envelope-afsenderen, så I kan sende svar til enhver indbakke, I selv kontrollerer.
• from_name — visningsnavnet i From, sat uafhængigt af From-adressen.
• headers — et objekt med header-navn → værdi, fx { "X-Order-Id": "10432" }. Navne skal matche [A-Za-z0-9][A-Za-z0-9-]*.

headers er en safelist, ikke passthrough. Disse navne er reserverede og kan ikke sættes: List-Unsubscribe, List-Unsubscribe-Post, From, Sender, Return-Path, Reply-To, DKIM-Signature, Received, og alt der starter med X-WeZend — alle matchet uden hensyn til store/små bogstaver. De beskytter overholdelse af one-click-afmelding, email-autentificering og envelope-identitet. Reply-To er reserveret, fordi det har sit eget validerede reply_to-felt; en rå header ville omgå den validering.

Et reserveret navn afvises og droppes ikke i stilhed, og fejlen navngiver den pågældende header:

{
  "to": "kunde@example.com",
  "channel": "email",
  "subject": "Jeres kvittering",
  "message": "Tak for din ordre.",
  "headers": { "List-Unsubscribe": "<mailto:opt-out@example.com>" }
}

{ "error": "Header \"List-Unsubscribe\" is reserved and cannot be set" }

Alle tre felter gemmes i beskedens send_options, så de overlever køen.

Planlægning og pr.-besked-webhooks

scheduled_at (ISO-tidsstempel) udsætter afsendelsen. webhook_url modtager leveringsstatusopdateringer for netop denne besked — se Webhooks.

Frekvenslofter for marketing

Send en category med (fx "newsletter") for at lade denne afsendelse tælle mod den pågældende kategoris frekvensloft, som konfigureres kontodækkende i messaging policy — uafhængigt af det globale loft på tværs af kanaler og af eventuelle lofter pr. kanal.

Transaktionelle afsendelser

Send transactional: true (boolean, eller strengen "true") for at markere en afsendelse som transaktionel — en nulstilling af adgangskode, en kvittering, en opt-in-bekræftelse. Standarden er false: en almindelig afsendelse er marketing.

Transaktionel mail er undtaget marketing-loftet for jeres bånd. Over loftet afregnes den pr. besked som overage i stedet for at blive afvist med quota_exceeded, så en tung kampagnemåned ikke kan sætte jeres adgangskode-mails helt i stå. Den tælles fortsat, så volumen forbliver synlig i forbrugsrapporteringen, og flaget gemmes på beskedrækken — det overlever køen og eventuelle genforsøg.

Der findes præcis ét kvote-tilfælde, hvor transaktionel mail stadig blokeres: en free-plan uden kort tilknyttet, hvor der ikke er nogen måde at afregne overage. region_blocked og payment_method_required er ikke kvotebeslutninger, så transactional tilsidesætter heller ikke dem.

transactional: true undtager desuden afsendelsen fra frekvenslofter og stilletimer.

Alle fire pr.-besked-felter — transactional, reply_to, from_name og headers — accepteres også pr. element i POST /v1/messages/bulk. Der fejler en ugyldig reply_to eller et reserveret header-navn kun det pågældende element (det tælles i failed) i stedet for at afvise hele batchen.

Response

{
  "message_id": "3fa1e2c0-...",
  "status": "queued",
  "channel": "sms",
  "to": "+4512345678",
  "cost": 0.045,
  "currency": "EUR",
  "created_at": "2026-07-08T10:00:00.000Z"
}

En 402 betyder utilstrækkelig saldo eller manglende betalingsmetode; 403 betyder at kontoen er suspenderet, afventer aktivering, eller at afsender-ID'et ikke er godkendt; 409 betyder at modtageren er afmeldt den kanal.