Hva er en webhook? Forskjellen fra API og bruk

01Hva er en webhook, og hvordan fungerer den?

Webhook er en enkel mekanisme som lar to programmer gi hverandre beskjed gjennom hendelser. Når noe skjer i et system (for eksempel at en betaling godkjennes), sender det en HTTP-forespørsel, oftest en POST-forespørsel, til en URL du har bestemt. I forespørselens innhold ligger detaljene om hendelsen, vanligvis i JSON-format.

Denne strukturen kalles av og til et omvendt API eller en hendelsestrigger. Det er nemlig systemet som produserer dataene, ikke det som ber om dem, som starter kommunikasjonen. Du sier bare én gang «gi meg beskjed på denne adressen når denne hendelsen skjer», og resten skjer automatisk.

For å forstå hvordan en webhook fungerer, er det lettere om du først kan svaret på hva er et API. Webhook er en del av API-verdenen, men retningen er snudd.

1. Hendelsen skjer: ny bestilling, returforespørsel, tom lagerbeholdning, godkjent betaling.
2. Kildesystemet sender en POST-forespørsel til den registrerte webhook-adressen.
3. Mottakersystemet validerer forespørselen, behandler dataene og svarer med noe som 200.
4. Kommer det ikke noe svar, prøver kildesystemet som regel forespørselen på nytt med jevne mellomrom.

02Forskjellen mellom webhook og API

Ved klassisk API-bruk spør klienten serveren med jevne mellomrom: «Er det noe nytt?» Denne metoden kalles polling. Finnes det ingen nye data, er hver forespørsel bortkastet. Finnes det data, må man vente til neste spørring.

Her kommer forskjellen mellom webhook og API inn: Med en webhook er det ingen som spør, bare noen som gir beskjed. Varselet kommer i det øyeblikket hendelsen skjer, og det oppstår ingen unødvendig trafikk. En webhook erstatter likevel ikke alt. For å liste historiske data, filtrere eller oppdatere poster trenger du fortsatt et API.

03Bruksområder for webhooks

Webhooks dukker opp i nesten alt digitalt arbeid. Betalingsleverandører, fraktselskaper, markedsplasser, e-posttjenester, kodelagre og kommunikasjonsverktøy sender som regel hendelsesvarsler med webhooks.

Netthandel og betaling

Når en kunde fullfører betalingen, sender betalingsløsningen et varsel om «vellykket betaling» til butikken din, og bestillingen bekreftes automatisk. Slik går bestillingen ikke tapt selv om nettleseren lukkes under betalinger med videresending som 3D Secure. Bestillingsflyten er kjernen i en nettbutikkintegrasjon.

Frakt og markedsplass

Når en forsendelse sendes eller leveres, kan fraktsystemet varsle om statusen, og kunden får automatisk en SMS eller e-post. På samme måte behandles hendelser som nye bestillinger, kanselleringer og returer umiddelbart i prosjekter for fraktintegrasjon og markedsplassintegrasjon.

Programvareutvikling og teamverktøy

Typiske webhook-scenarier er å starte tester og publiseringsprosessen når en ny commit sendes til kodelageret, å sende et varsel til teamets meldingskanal når et skjema fylles ut, eller å oppdatere kalenderen når en reservasjon kommer inn.

04Eksempel på en webhook-forespørsel

En webhook-forespørsel inneholder som regel hendelsestypen, tidspunktet og dataene for den aktuelle posten. Eksemplet nedenfor er et typisk innhold som kan sendes når en bestilling opprettes. Feltnavnene er forskjellige for hver tjeneste, så bruk tjenestens egen dokumentasjon som utgangspunkt.

På mottakersiden holder det med et lite endepunkt som tar imot forespørselen. Nedenfor ser du et enkelt eksempel skrevet med Node.js og Express. I et reelt prosjekt må signaturvalidering og køstruktur legges til.

{
  "event": "order.created",
  "created_at": "2026-01-15T10:24:00Z",
  "data": {
    "order_id": "10458",
    "total": 1249.90,
    "currency": "TRY",
    "status": "paid"
  }
}

const express = require('express');
const app = express();

app.post('/webhooks/siparis', express.json(), (req, res) => {
  const olay = req.body;
  // 1) Verifiser signaturen  2) Legg i køen  3) Svar umiddelbart
  console.log('Gelen olay:', olay.event);
  res.sendStatus(200);
});

app.listen(3000);

05Hvordan sikrer man en webhook?

En webhook-adresse er et endepunkt som er åpent mot internett. Alle som kjenner adressen, kan sende falske forespørsler dit. Derfor bør du ikke stole på noen forespørsel som kommer uten signaturvalidering.

De fleste seriøse tjenester signerer forespørselen med en delt hemmelig nøkkel og sender signaturen i en HTTP-header. Mottakersystemet gjør samme beregning og sammenligner signaturene. Forespørsler som ikke stemmer, avvises.

• Bruk bare HTTPS-adresser, og send aldri data over vanlig HTTP.
• Bruk valideringsmetoder som HMAC-signatur.
• Sjekk tidsstempelet i forespørselen for å hindre at gamle forespørsler spilles av på nytt.
• Ikke skriv den hemmelige nøkkelen i kodelageret. Lagre den i en miljøvariabel.
• Kontroller skjemaet til innkommende data før du skriver dem direkte til databasen.

06Vanlige feil og løsninger

Det er enkelt å sette opp en webhook, men det krever oppmerksomhet å få den til å kjøre stabilt. Problemene man oftest møter i prosjekter, er forespørsler som kommer flere ganger og trege svar.

Samme hendelse behandles to ganger

Når kildesystemet ikke får svar, sender det forespørselen på nytt, så den samme bestillingen kan komme to ganger. Løsningen er en idempotent utforming: Lagre den unike id-en til hver hendelse, og kommer en id som allerede er behandlet, svarer du bare med suksess og går videre.

Tidsavbrudd

Hvis endepunktet prøver å gjøre lange oppgaver som å utstede en faktura eller sende e-post samtidig som det mottar forespørselen, blir svaret forsinket, og kildesystemet registrerer en feil. Den riktige metoden er å ta imot forespørselen, legge den i en jobbkø og svare med en gang. De tunge oppgavene kjøres i bakgrunnen.

Feil rekkefølge

Hendelser kommer ikke alltid i den rekkefølgen de skjedde. Varselet «sendt» kan komme før varselet «betalt». Lagre tidspunktet for hendelsen i postene dine, og vurder statusendringene etter dette tidspunktet.

07Webhook eller ferdig automatiseringsverktøy?

I enkle scenarier kan automatiseringsverktøy som lytter etter webhooks gjøre jobben uten koding. Styrkene og svakhetene til slike verktøy har vi gått gjennom i artikkelen hva er low-code. I flyter som er kjernen i virksomheten, som bestilling, betaling og lager, er det likevel viktig at du har kontrollen.

Har du spesielle forretningsregler, kobler flere systemer sammen eller har økende datavolum, er det mer pålitelig å bygge webhook-arkitekturen inn i din egen programvare. Her reduserer tilnærmingen med skreddersydd programvareutvikling avhengigheten av mellomlag.

Tilnærmingen i programvareløsningene og de integrerte løsningene til Aurora bygger også på dette prinsippet: Systemene snakker direkte med hverandre, og unødvendige lag mellom dem fjernes.

08Sjekkliste før du setter opp en webhook

Å svare på spørsmålene nedenfor før du bygger en automatisk varslingsløsning forhindrer de fleste problemene som ellers dukker opp senere.

1. Hvilke hendelser trengs egentlig? Å abonnere på alle hendelser gir unødvendig belastning.
2. Er endepunktet tilgjengelig over HTTPS, og gjør det signaturvalidering?
3. Lagres en unik id for hendelser som kommer flere ganger?
4. Logges mislykkede forespørsler, og kan de overvåkes?
5. Finnes det en reservekontroll som henter inn data via API hvis en webhook ikke kommer?
6. Kontrolleres risikoen for dobbeltføring i kritiske trinn som regnskap og fakturering med regnskapsintegrasjon?