Send et nyhetsbrev fra ditt eget system
Alle sidene
Kom i gang
Nettbutikk
Publikasjon
Nøkkelen trengernewsletter:writesubscribers:writebroadcasts:writenewsletter:sendLag en nøkkel →
Sett utseendet én gang
E-posten går ut i publikasjonens egen logo, skrift, hilsen og signatur. 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 AcceptedIkke 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.
Send den, eller sett den på et tidspunkt
En nøkkel som bare har broadcasts:write, 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. Nøkkelen hører til utsendingen, ikke til forsøket.
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. 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
}
}
}