Send et nyhetsbrev fra ditt eget system

Sett utseendet én gang

E-posten går ut i publikasjonens egen logo, skrift, hilsen og signatur. Du setter det én gang, og hver e-post etterpå arver det. Utseendet følger ikke med i kallet, og det finnes ikke noe HTML-felt å fylle.

PATCH /v1/newsletter endrer bare det du sender. Feltene du lar være, står som de står.

curl -X PATCH https://api.skribb.no/v1/newsletter \
  -H "Authorization: Bearer skribb_sk_…" \
  -H "Content-Type: application/json" \
  -d '{
        "greeting": "Hei,",
        "signoff": "Hilsen Kari",
        "reply_to": "kari@eksempel.no"
      }'

Svaret har mirrored. Er den false, er oppsettet lagret her, men kom ikke fram til publikasjonen ennå. Da går det ut ved neste lagring, og e-posten du sender i mellomtida bruker det forrige oppsettet.

Få folk på lista uten å forfalske et ja

POST /v1/subscribers ber en adresse om å bekrefte. Den får den samme e-posten som når noen melder seg på selv, og blir abonnent når de trykker på lenka. Det finnes ingen parameter som hopper over det.

curl -X POST https://api.skribb.no/v1/subscribers \
  -H "Authorization: Bearer skribb_sk_…" \
  -H "Content-Type: application/json" \
  -d '{"email": "ny@eksempel.no"}'

# 202 Accepted

Ikke spør etter adressen etterpå. Den dukker ikke opp i GET /v1/subscribers før den er bekreftet, så en integrasjon som leter etter den og sender på nytt når den ikke er der, sender e-post til den samme personen om og om igjen. Lytt på subscriber.confirmed i stedet, og på subscriber.unsubscribed når noen går motsatt vei.

Skal du flytte en liste med folk som allerede har sagt ja, gjør du det i oversikten, ikke herfra. Der står et menneske for at samtykket finnes.

Skriv utsendingen

En utsending er emne og tekst. Send markdown, eller Portable Text i body hvis du har det, aldri begge. Uten send og uten scheduled_for blir den et utkast, og ingenting går ut.

curl -X POST https://api.skribb.no/v1/broadcasts \
  -H "Authorization: Bearer skribb_sk_…" \
  -H "Content-Type: application/json" \
  -d '{
        "subject": "Ukas brev",
        "markdown": "Det ble en lang uke.\n\nHer er det jeg skrev.",
        "post_slugs": ["sommerbrev", "om-prisene"],
        "audience": "all"
      }'

post_slugs blir innleggskort under teksten. Publikasjonen slår dem opp i det e-posten går ut, så et innlegg du avpubliserer i mellomtida faller ut av brevet i stedet for å bli en død lenke i innboksen til alle.

Send den, eller sett den på et tidspunkt

Å skrive og å sende er to tilganger. broadcasts:write lager, planlegger og avlyser; alt som faktisk havner i en innboks krever newsletter:send i tillegg. En nøkkel som bare har den første, kan skrive hele utsendingen og blir avvist på siste kall.

Tell mottakerne først. dry_run svarer med hvor mange den ville gått til, uten å sende noe og uten å kreve Idempotency-Key, og avviser det samme et ekte kall ville avvist.

curl -X POST https://api.skribb.no/v1/broadcasts/6f1c2a90/send \
  -H "Authorization: Bearer skribb_sk_…" \
  -H "Content-Type: application/json" \
  -d '{"dry_run": true}'

# { "send": { "dry_run": true, "recipient_count": 412, … } }

curl -X POST https://api.skribb.no/v1/broadcasts/6f1c2a90/send \
  -H "Authorization: Bearer skribb_sk_…" \
  -H "Idempotency-Key: ukas-brev-2026-09-04" \
  -H "Content-Type: application/json" \
  -d '{}'

Idempotency-Key er påkrevd på et ekte kall. Går svaret tapt på veien tilbake, er det trygt å sende den samme forespørselen om igjen: du får svaret fra første gang i stedet for en e-post til. Nøkkelen hører til utsendingen og ikke til forsøket, så prøver du igjen, bruker du den samme.

Send scheduled_for i stedet, og det samme kallet blir en bestilling. Ingenting går ut nå, utsendingen står som planlagt, og DELETE avlyser den helt til tidspunktet kommer.

Status og de to hendelsene

Kallet svarer når publikasjonen har tatt imot lista, ikke når siste e-post er levert. På en lang liste betyr det at status fortsatt er sender når du får svaret, og at tallene i det er delsummer.

Slå på broadcast.sent. Den kommer når alt er ute, med recipient_count og sent_count ferdig talt opp.

broadcast.failed er den andre halvparten. Nådde vi ikke publikasjonen, prøver vi i to timer og gir oss så, og utsendingen står som feilet. Kallet ditt svarte for lenge siden, så uten denne hendelsen oppdager du det først når noen spør hvorfor brevet aldri kom. Du kan sende den om igjen når publikasjonen svarer, og ingen får den to ganger.

{
  "id": "3f9a1c7e-…",
  "event": "broadcast.sent",
  "created_at": "2026-09-04T09:12:04.000Z",
  "data": {
    "broadcast": {
      "id": "6f1c2a90",
      "subject": "Ukas brev",
      "status": "sendt",
      "recipient_count": 412,
      "sent_count": 411,
      "failed_count": 1
    }
  }
}

Videre

Referansen for det denne guiden bruker:

• Abonnenter →
• Nyhetsbrev →
• Utsendinger →
• Alle guidene →