Vad är en webhook? Skillnad mot API och användning

01Vad är en webhook och hur fungerar den?

Webhook är en enkel mekanism som låter två mjukvaror meddela varandra via händelser. När något händer inuti ett system (till exempel när en betalning godkänns) skickar det en HTTP-förfrågan, oftast en POST-förfrågan, till en URL som du har angett. Förfrågans kropp innehåller händelsens detaljer, vanligtvis i JSON-format.

Strukturen kallas ibland omvänt API eller händelseutlösare. Det beror på att den som startar kommunikationen är systemet som producerar datan, inte det som ber om den. Du säger bara en gång »meddela mig på den här adressen när den här händelsen inträffar«, och resten sker automatiskt.

För att förstå hur en webhook fungerar är det en fördel att först känna till svaret på frågan vad är ett API. En webhook är en del av API-världen, men riktningen är omvänd.

1. Händelsen inträffar: ny order, returförfrågan, slut i lager, godkänd betalning.
2. Källsystemet skickar en POST-förfrågan till den registrerade webhook-adressen.
3. Mottagarsystemet validerar förfrågan, bearbetar datan och svarar med en 200-liknande kod.
4. Uteblir svaret försöker källsystemet oftast skicka förfrågan igen med vissa intervall.

02Skillnaden mellan webhook och API

Vid klassisk API-användning frågar klienten servern med jämna mellanrum »finns det något nytt?«. Metoden kallas polling. Finns ingen ny data går varje förfrågan till spillo, och finns det data måste man vänta till nästa förfrågan.

Här syns skillnaden mellan webhook och API: med en webhook finns ingen som frågar, bara någon som meddelar. Aviseringen kommer i samma stund som händelsen inträffar, och onödig trafik uppstår inte. En webhook ersätter dock inte allt. För att lista, filtrera historiska data eller uppdatera poster behövs fortfarande ett API.

03Användningsområden för webhooks

Webhooks dyker upp i nästan alla digitala sammanhang. Betalningsleverantörer, fraktbolag, marknadsplatser, e-posttjänster, kodförråd och kommunikationsverktyg skickar oftast händelseaviseringar via webhooks.

E-handel och betalning

När en kund slutfört sin betalning skickar betalningsplattformen en avisering till din butik om att betalningen lyckades, och ordern bekräftas automatiskt. Det är tack vare detta som ordern inte försvinner vid betalningar med omdirigering som 3D Secure, även om webbläsaren stängs. Orderflödet är centralt i en e-handelsintegration.

Frakt och marknadsplatser

När en försändelse lämnar eller levereras kan fraktsystemet meddela status, och kunden får ett automatiskt SMS eller e-postmeddelande. På liknande sätt behandlas händelser som nya ordrar, annulleringar och returer direkt i projekt för fraktintegration och marknadsplatsintegration.

Mjukvaruutveckling och teamverktyg

Att starta tester och releaseprocessen när en ny commit skickas till kodförrådet, att skicka en avisering till teamets meddelandekanal när ett formulär fylls i eller att uppdatera kalendern när en bokning kommer in är typiska webhook-scenarier.

04Exempel på en webhook-förfrågan

En webhook-förfrågan bär oftast händelsens typ, tidpunkt och data för den aktuella posten. Exemplet nedan är en typisk kropp som kan skickas när en order skapas. Fältnamnen är olika för varje tjänst, så utgå från tjänstens egen dokumentation.

På mottagarsidan räcker en liten slutpunkt som tar emot förfrågan. Nedan ser du ett enkelt exempel skrivet med Node.js och Express. I ett verkligt projekt måste signaturverifiering och en köstruktur läggas till.

{
  "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) Verifiera signaturen  2) Lägg i kön  3) Svara direkt
  console.log('Gelen olay:', olay.event);
  res.sendStatus(200);
});

app.listen(3000);

05Hur säkrar man en webhook?

En webhook-adress är en slutpunkt som är öppen mot internet. Den som känner till adressen kan skicka falska förfrågningar dit. Därför ska man inte lita på någon förfrågan som kommer utan signaturverifiering.

De flesta seriösa tjänster signerar förfrågan med en delad hemlig nyckel och skickar signaturen i en HTTP-header. Mottagarsystemet gör samma beräkning och jämför signaturerna, och en förfrågan som inte stämmer avvisas.

• Använd bara HTTPS-adresser och skicka aldrig data över vanlig HTTP.
• Tillämpa alltid verifieringsmetoder som HMAC-signatur.
• Kontrollera tidsstämpeln i förfrågan för att förhindra att gamla förfrågningar spelas upp igen.
• Skriv inte den hemliga nyckeln i kodförrådet, utan spara den i en miljövariabel.
• Kontrollera schemat på inkommande data innan du skriver den direkt i databasen.

06Vanliga fel och lösningar

Det är lätt att sätta upp en webhook men det krävs omsorg för att få den att fungera stabilt. De problem som oftast förekommer i projekt är förfrågningar som kommer flera gånger och långsamma svar.

Samma händelse behandlas två gånger

När källsystemet inte får något svar skickar det förfrågan igen, så samma order kan komma två gånger. Lösningen är en idempotent design: spara ett unikt id för varje händelse, och kommer ett redan behandlat id svarar du bara med ett lyckat svar och går vidare.

Tidsgräns överskrids

Om slutpunkten försöker utföra långa uppgifter som att skapa en faktura eller skicka e-post medan förfrågan tas emot dröjer svaret och källsystemet räknar det som ett fel. Det rätta tillvägagångssättet är att ta emot förfrågan, lägga den i en jobbkö och svara direkt, medan de tunga uppgifterna körs i bakgrunden.

Fel ordning

Händelser kommer inte alltid i den ordning de inträffade. Aviseringen »skickad« kan nå dig före aviseringen »betald«. Spara händelsens tidpunkt i dina poster och bedöm statusövergångarna utifrån den.

07Webhook eller färdigt automationsverktyg?

I enkla scenarier kan automationsverktyg som lyssnar på webhooks göra jobbet utan kod. Verktygens styrkor och svagheter har vi gått igenom i artikeln Vad är low-code. I flöden som ligger i verksamhetens kärna, som order, betalning och lager, är det dock viktigt att du har kontrollen.

Är dina affärsregler specifika, kopplas flera system samman eller växer datavolymen är det mer tillförlitligt att bygga webhook-arkitekturen in i din egen mjukvara. Här minskar arbetssättet skräddarsydd mjukvaruutveckling beroendet av mellanlager.

Auroras mjukvarulösningar och integrerade lösningar bygger också på den principen: systemen talar direkt med varandra, och onödiga mellanlager tas bort.

08Checklista innan du sätter upp en webhook

Att svara på frågorna nedan innan du bygger en infrastruktur för automatiska aviseringar förebygger de flesta problem som annars dyker upp senare.

1. Vilka händelser behövs verkligen? Att prenumerera på alla händelser skapar onödig belastning.
2. Är slutpunkten nåbar via HTTPS och gör den signaturverifiering?
3. Sparas ett unikt id för händelser som kommer flera gånger?
4. Loggas misslyckade förfrågningar och går de att följa upp?
5. Finns det en reservkontroll som återhämtar data med ett API om en webhook uteblir?
6. Kontrolleras risken för dubbelregistrering i kritiska steg som bokföring och fakturering med en bokföringsintegration?