Hvad er en webhook?
En webhook er et omvendt API-kald: I stedet for at I spørger et system igen og igen om noget er sket, ringer systemet selv til jer i samme øjeblik en hændelse indtræffer. En betaling gennemføres, en ordre sendes, en aftale underskrives, og der går straks en besked af sted. Webhooks er effektive, men kan gå tabt og kræver en kvittering.
Webhook er et ord der lyder teknisk, men bygger på en idé fra hverdagen. Hvis et almindeligt API handler om at spørge et system om noget, handler en webhook om det omvendte: at få besked. Det er en lille forskel i retning med store konsekvenser for hvor hurtigt og effektivt systemer kan reagere på hinanden. Her er forklaringen, med en sammenligning der gør princippet indlysende.
Dørklokken over for postkassen
Forestil dig at du venter på en vigtig pakke. Én måde er at gå ud til postkassen hvert femte minut og se efter om den er kommet. De fleste gange står du der forgæves, og alligevel kan pakken have ligget og ventet et stykke tid før du opdagede den.
Den anden måde er at have en dørklokke. Så behøver du slet ikke gå ud og se efter. I samme øjeblik pakken bliver leveret, ringer det, og du reagerer med det samme. Ingen unødvendig venten, ingen forsinkelse.
En webhook er dørklokken. I stedet for at jeres system spørger et andet igen og igen “er der sket noget?”, sender det andet system af sig selv en lille besked i det øjeblik noget faktisk sker. Derfor kaldes en webhook ofte et omvendt API-kald: Normalt er det jer der ringer op, men her er det systemet der ringer til jer.
Hvad det betyder i praksis
Forskellen fra at spørge hele tiden handler ikke kun om elegance, men om effektivitet. At spørge et system med faste mellemrum betyder masser af kald hvor svaret alligevel bliver “intet nyt”, plus en forsinkelse indtil næste spørgsmål når at blive stillet. En webhook sender først besked når der er noget at fortælle, og gør det med det samme.
Resultatet er både friskere information og mindre belastning af begge systemer. I får ting at vide i samme øjeblik de sker uden at spilde kald på at spørge forgæves. For flows der skal føles øjeblikkelige, er det ofte forskellen mellem noget der svarer med det samme og noget der altid halter et par minutter bagefter.
Forretningseksempler
Webhooks er usynlige, men driver hændelsesforløb I møder hver dag. Et par typiske:
- Betaling gennemført. Når en kunde betaler, sender betalingstjenesten en webhook til jer i samme øjeblik pengene går igennem. I kan så bekræfte ordren med det samme uden at sidde og spørge betalingstjenesten igen og igen om betalingen er kommet.
- Ordren afsendt. Når en ordre bliver pakket og sendt, kan lager- eller logistiksystemet sende en webhook så kunden får sin advisering og status opdateres automatisk.
- Aftalen underskrevet. Når et dokument er underskrevet i en aftaletjeneste, sendes der en webhook, og jeres system kan gå videre med næste trin (aktivere tjenesten, oprette kunden, starte leverancen) uden at nogen behøver at kontrollere det manuelt.
Fælles for alle tre: En hændelse i ét system udløser straks en reaktion i et andet uden at et menneske flytter informationen eller et system sidder og spørger.
En vigtig note om leveringsgarantier
Der er dog en hage som er værd at kende. En webhook kan forsvinde. Beskeden bliver måske sendt lige når jeres modtager er nede, den kan gå tabt et sted undervejs, eller den kan ved et uheld blive sendt to gange. Modsat når I selv spørger (og kan spørge igen hvis svaret udebliver), er I afhængige af at afsenderen når frem i det rigtige øjeblik.
Derfor bygges webhooks med to former for beskyttelse. Afsenderen laver genforsøg hvis beskeden ikke når frem, gerne med stigende mellemrum. Og modtageren sender en kvittering, en bekræftelse på at beskeden er modtaget. Får afsenderen ingen kvittering, prøver den igen indtil det lykkes. Tilsammen sørger de for at ingen hændelser i stilhed falder mellem to stole.
Det gør ikke webhooks upålidelige (rigtigt bygget er de meget robuste), men det forklarer hvorfor en gennemtænkt webhook-integration er mere end bare at tage imod et kald.
Vi hos Weapp bygger integrationer på webhooks og sørger for at de kan tåle virkeligheden, med genforsøg og kvitteringer på plads. Se vores ydelser eller kontakt os.
Ofte stillede spørgsmål
Hvad er forskellen på en webhook og et almindeligt API-kald?
Retningen. Med et almindeligt API-kald er det jer der spørger et andet system om noget. Med en webhook er det omvendt: Det andet system kontakter jer af sig selv når der sker noget. Netop derfor kalder man webhooken et omvendt API-kald. I venter på besked i stedet for at spørge, hvilket sparer masser af unødvendige kald.
Hvorfor er en webhook mere effektiv end at spørge hele tiden?
Fordi I slipper for alle de kald hvor svaret alligevel er at intet er sket. At spørge et system med faste mellemrum betyder masser af unødvendige forespørgsler og alligevel en forsinkelse til næste spørgsmål. En webhook sender først besked når noget faktisk sker, og med det samme. I får friskere information og belaster begge systemer mindre. Det er mere effektivt på begge måder.
Kan en webhook gå tabt?
Ja, og det er dens svage punkt. Et webhook-kald kan blive sendt mens jeres modtager er nede, gå tabt undervejs eller ved en fejl komme frem to gange. Modsat når I selv spørger, er I afhængige af at afsenderen når frem i det rigtige øjeblik. Derfor skal webhooks bygges med genforsøg og en kvittering der bekræfter at beskeden blev modtaget.
Hvad er en kvittering i den sammenhæng?
Et svar fra jer som bekræfter at I har modtaget webhooken. Når afsenderen får kvitteringen, ved den at den ikke behøver at sende igen. Udebliver den, prøver afsenderen på ny. Kvitteringen er det der sikrer at ingen hændelser forsvinder i stilhed: Enten bekræftes de, eller også sendes de igen indtil de når frem. Uden den ved ingen om kaldet lykkedes.
Hvor bruges webhooks i praksis?
Overalt hvor et system med det samme skal have at vide at der er sket noget i et andet. Betalingstjenester sender en webhook når en betaling går igennem, e-handelssystemer når en ordre sendes, aftaletjenester når et dokument er underskrevet. Jeres integration reagerer så i samme øjeblik i stedet for at opdage hændelsen sent. Det er rygraden i flows der skal føles øjeblikkelige.