Skicka meddelanden

POST /v1/messages/send är den enda endpointen för alla kanaler.

Obligatoriska fält

to, channel (en av sms, rcs, whatsapp, email, voice) och message är obligatoriska — eller skicka en channels-array i stället för channel/fallback (se nedan).

Kanalfallback

Ange en ordnad fallback-lista, eller den nyare channels-arrayen med primärkanalen först:

{
  "to": "+4512345678",
  "channels": ["whatsapp", "sms"],
  "message": "Din order har skickats."
}

Om WhatsApp-leveransen misslyckas gör plattformen automatiskt ett nytt försök via SMS — utan något separat API-anrop.

Kanalspecifika fält

• E-post: sätt subject, och htmlmessage (eller det äldre aliaset html) för HTML-bodyn. message är fallbacken i klartext.
• WhatsApp: skicka ett whatsapp-objekt, t.ex. { "template": "order_shipped" }, för mallmeddelanden utanför 24-timmarsfönstret för sessioner.
• Voice: skicka ett voice-objekt (t.ex. { "voice": "female", "language": "da-DK" }) för TTS-parametrar.
• Avsändar-ID: sender måste vara ett avsändar-ID som godkänts i Inställningar → Avsändar-ID:n för SMS/RCS — såvida inte ditt konto har allow_unverified_sender aktiverat för systemintegrationer.

Reply-To, avsändarnamn och egna headers

Tre valfria e-postfält:

• reply_to — dit svaren går. Antingen en ren adress (support@dittforetag.se) eller formen med visningsnamn (Support <support@dittforetag.se>); adressdelen valideras som en e-postadress. Fältet är medvetet inte domänlåst — Reply-To är inte envelope-avsändaren, så du kan låta svar gå till vilken inkorg du än kontrollerar.
• from_name — visningsnamnet i From, satt oberoende av From-adressen.
• headers — ett objekt med headernamn → värde, t.ex. { "X-Order-Id": "10432" }. Namn måste matcha [A-Za-z0-9][A-Za-z0-9-]*.

headers är en safelist, inte passthrough. Dessa namn är reserverade och kan inte sättas: List-Unsubscribe, List-Unsubscribe-Post, From, Sender, Return-Path, Reply-To, DKIM-Signature, Received, och allt som börjar med X-WeZend — samtliga matchade oberoende av versaler och gemener. De skyddar efterlevnaden av one-click-avregistrering, e-postautentiseringen och envelope-identiteten. Reply-To är reserverat eftersom det har ett eget validerat reply_to-fält; en rå header skulle kringgå den valideringen.

Ett reserverat namn avvisas, det tas inte bort tyst, och felet namnger den aktuella headern:

{
  "to": "kund@example.com",
  "channel": "email",
  "subject": "Ditt kvitto",
  "message": "Tack för din order.",
  "headers": { "List-Unsubscribe": "<mailto:opt-out@example.com>" }
}

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

Alla tre fälten lagras i meddelandets send_options och överlever därmed kön.

Schemaläggning och webhooks per meddelande

scheduled_at (ISO-tidsstämpel) fördröjer utskicket. webhook_url tar emot leveransstatusuppdateringar för just det här meddelandet — se Webhooks.

Frekvenstak för marknadsföring

Skicka med en category (t.ex. "newsletter") för att låta utskicket räknas mot den kategorins frekvenstak, som konfigureras kontoövergripande i sändningspolicyn — oberoende av det globala kanalöverskridande taket och eventuella tak per kanal.

Transaktionella utskick

Skicka transactional: true (booleanen, eller strängen "true") för att märka ett utskick som transaktionellt — en lösenordsåterställning, ett kvitto, en opt-in-bekräftelse. Standardvärdet är false: ett vanligt utskick är marknadsföring.

Transaktionell e-post är undantagen marknadsföringstaket för ditt band. Över taket faktureras den per meddelande som overage i stället för att avvisas med quota_exceeded, så en tung kampanjmånad kan inte tvärstoppa dina lösenordsmejl. Den räknas fortfarande, så volymen syns i förbrukningsrapporteringen, och flaggan lagras på meddelanderaden — den överlever kön och eventuella omförsök.

Det finns exakt ett kvotfall där transaktionell e-post ändå blockeras: en free-plan utan kort registrerat, där det inte finns något sätt att fakturera överskottet. region_blocked och payment_method_required är inte kvotbeslut, så transactional åsidosätter inte dem heller.

transactional: true undantar dessutom utskicket från frekvenstak och tysta timmar.

Alla fyra fälten per utskick — transactional, reply_to, from_name och headers — accepteras även per post i POST /v1/messages/bulk. Där gör en ogiltig reply_to eller ett reserverat headernamn att bara den posten misslyckas (den räknas i failed) i stället för att hela batchen avvisas.

Svar

{
  "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 otillräckligt saldo eller saknad betalningsmetod; 403 betyder att kontot är avstängt, väntar på aktivering, eller att avsändar-ID:t inte är godkänt; 409 betyder att mottagaren har avregistrerat sig från den kanalen.