Vad är en webhook?
En webhook är ett omvänt API-anrop: i stället för att ni frågar ett system om och om igen om något hänt, ringer systemet självt upp er i samma stund en händelse sker. En betalning genomförs, en order skickas, ett avtal signeras – och ett meddelande skickas direkt. Webhooks är effektiva men kan tappas bort och behöver kvittens.
Webhook är ett ord som låter tekniskt men bygger på en vardaglig idé. Om ett vanligt API handlar om att fråga ett system om något, handlar en webhook om det omvända: att bli tillsagd. Det är en liten skillnad i riktning med stora konsekvenser för hur snabbt och effektivt system kan reagera på varandra. Här är förklaringen, med en liknelse som gör principen självklar.
Dörrklockan mot brevlådan
Tänk dig att du väntar på ett viktigt paket. Ett sätt är att gå ut till brevlådan var femte minut och titta efter om det kommit. De flesta gångerna står du där i onödan, och ändå kan paketet ha legat och väntat en stund innan du upptäckte det.
Det andra sättet är att ha en dörrklocka. Då behöver du inte gå ut och titta alls. I samma stund paketet levereras ringer det, och du reagerar direkt. Ingen väntan i onödan, ingen fördröjning.
En webhook är dörrklockan. I stället för att ert system frågar ett annat om och om igen “har något hänt?”, skickar det andra systemet självmant ett litet meddelande i det ögonblick något faktiskt sker. Därför kallas en webhook ofta ett omvänt API-anrop: vanligtvis är det ni som ringer upp, men här är det systemet som ringer er.
Vad det innebär i praktiken
Skillnaden mot att fråga hela tiden är inte bara elegans, den är effektivitet. Att regelbundet fråga ett system innebär massor av anrop där svaret ändå blir “inget nytt”, plus en fördröjning tills nästa fråga hinner ställas. En webhook skickar besked först när det finns något att berätta, och gör det direkt.
Resultatet blir både färskare information och mindre belastning på båda systemen. Ni får veta saker i samma stund de händer, utan att slösa anrop på att fråga i onödan. För flöden som ska kännas omedelbara är det ofta skillnaden mellan något som svarar direkt och något som alltid ligger några minuter efter.
Affärsexempel
Webhooks är osynliga men driver händelseflöden ni möter dagligen. Några typiska:
- Betalning genomförd. När en kund betalar skickar betaltjänsten en webhook till er i samma stund pengarna går igenom. Ni kan då bekräfta ordern direkt, utan att sitta och fråga betaltjänsten om och om igen om betalningen kommit.
- Ordern skickad. När en order packas och skickas kan lager- eller logistiksystemet skicka en webhook, så att kunden får sin avisering och statusen uppdateras automatiskt.
- Avtalet signerat. När ett dokument signerats i en avtalstjänst skickas en webhook, och ert system kan gå vidare med nästa steg – aktivera tjänsten, skapa kunden, starta leveransen – utan att någon behöver kontrollera manuellt.
Gemensamt för alla tre: en händelse i ett system utlöser omedelbart en reaktion i ett annat, utan att en människa flyttar informationen eller ett system sitter och frågar.
En viktig not om leveransgarantier
Här finns dock en hake som är värd att känna till. En webhook kan försvinna. Meddelandet skickas kanske precis när er mottagare är nere, det kan tappas någonstans på vägen, eller råka skickas två gånger. Till skillnad från när ni själva frågar – och kan fråga igen om svaret uteblir – är ni beroende av att avsändaren når fram i rätt ögonblick.
Därför byggs webhooks med två skydd. Avsändaren gör omförsök om meddelandet inte når fram, gärna med ökande mellanrum. Och mottagaren skickar en kvittens, en bekräftelse på att meddelandet tagits emot. Får avsändaren ingen kvittens försöker den igen tills det går fram. Tillsammans ser de till att inga händelser tyst faller mellan stolarna.
Det gör inte webhooks opålitliga – rätt byggda är de mycket robusta – men det förklarar varför en genomtänkt webhook-integration är mer än att bara ta emot ett anrop.
Vi på Weapp bygger integrationer på webhooks och ser till att de tål verkligheten, med omförsök och kvittenser på plats. Titta på våra tjänster eller hör av dig.
Vanliga frågor
Vad är skillnaden mellan en webhook och ett vanligt API-anrop?
Riktningen. Med ett vanligt API-anrop är det ni som frågar ett annat system om något. Med en webhook är det tvärtom: det andra systemet kontaktar er självmant när något händer. Man brukar kalla webhooken ett omvänt API-anrop av just den anledningen. Ni väntar på besked i stället för att fråga, vilket sparar mängder av onödiga anrop.
Varför är en webhook effektivare än att fråga hela tiden?
För att ni slipper alla de anrop där svaret ändå blir att inget hänt. Att fråga ett system regelbundet innebär massor av förfrågningar i onödan och ändå en fördröjning tills nästa fråga. En webhook skickar besked först när något faktiskt sker, direkt. Ni får färskare information och belastar båda systemen mindre. Det är effektivare på båda sätten.
Kan en webhook missa att komma fram?
Ja, och det är dess svaga punkt. Ett webhook-anrop kan skickas när er mottagare är nere, tappas på vägen eller råka komma två gånger. Till skillnad från när ni själva frågar är ni beroende av att avsändaren når fram i rätt ögonblick. Därför behöver webhooks byggas med omförsök och en kvittens som bekräftar att meddelandet togs emot.
Vad är en kvittens i sammanhanget?
Ett svar från er som bekräftar att ni tagit emot webhooken. När avsändaren får kvittensen vet den att den inte behöver skicka igen. Uteblir den, försöker avsändaren på nytt. Kvittensen är det som gör att inga händelser tyst försvinner: antingen bekräftas de, eller så skickas de om tills de går fram. Utan den vet ingen om anropet lyckades.
Var används webhooks i praktiken?
Överallt där ett system behöver få veta att något hänt i ett annat direkt. Betaltjänster skickar en webhook när en betalning går igenom, e-handelssystem när en order skickas, avtalstjänster när ett dokument signerats. Er integration reagerar då i samma stund i stället för att upptäcka händelsen sent. Det är ryggraden i flöden som ska kännas omedelbara.