Vad är webhooks? Så fungerar de — och så övervakar du dem

En webhook är ett HTTP-anrop som en tjänst skickar automatiskt till din server när något specifikt händer — en betalning genomförs, ett dokument uppdateras, en beställning läggs. Istället för att du frågar "har något hänt?" gång på gång, berättar avsändaren själv, direkt när det sker.

Push, inte pull

Skillnaden mot ett vanligt API handlar om vem som initierar anropet. Med ett API anropar du en endpoint när du vill ha information — du frågar, servern svarar. Med en webhook är det tvärtom: du registrerar en URL hos avsändaren i förväg, och avsändaren anropar den URL:en själv, när ett event inträffar. Du behöver aldrig fråga; informationen kommer till dig.

Det gör webhooks effektiva för händelsestyrd integration. En betaltjänst som Stripe skickar en webhook när en betalning går igenom istället för att du ska behöva fråga "är den klar än?" var tionde sekund. Ett CMS skickar en webhook när en artikel publiceras istället för att din server ska behöva polla efter ändringar.

Så fungerar det tekniskt

I grunden är en webhook ett vanligt HTTP POST-anrop till en URL du angett, med en payload (oftast JSON) som beskriver vad som hände:

curl -X POST https://din-server.se/webhooks/betalning \
  -H "Content-Type: application/json" \
  -H "X-Signature: sha256=a1b2c3..." \
  -d '{"event": "payment.succeeded", "amount": 499, "currency": "SEK"}'

Det finns ingen formell standard för hur webhooks ska se ut — varken payload-format, headers eller retry-beteende är standardiserat mellan tjänster. Varje leverantör bygger sin egen variant ovanpå samma grundmönster: HTTP POST plus JSON.

HMAC-signaturer

Eftersom vem som helst i princip kan skicka ett POST-anrop till din endpoint, behöver du kunna verifiera att anropet faktiskt kommer från rätt avsändare. Den vanliga lösningen är HMAC-signering: avsändaren och du delar en hemlig nyckel. Avsändaren räknar ut en hash av payloaden med den nyckeln och skickar hashen i en header (till exempel X-Signature). Din server räknar ut samma hash själv och jämför — matchar de, är anropet äkta.

Vanliga fallgropar

Endpointen svarar för långsamt. De flesta avsändare väntar bara några sekunder på svar innan de ger upp anropet. Gör tunga bearbetningssteg asynkront efter att du svarat 200 OK, inte innan.

Ingen hantering av dubbletter. Nätverksfel och omförsök gör att samma event ibland levereras mer än en gång. Design din endpoint för att vara idempotent — att bearbeta samma event två gånger ska inte orsaka dubbla effekter.

Ingen övervakning av själva endpointen. En webhook-endpoint som slutar svara — på grund av en deploy, ett krasch eller ett certifikat som gått ut — missar events tyst. Om avsändaren inte gör om anropet för evigt är de eventsen borta permanent, och ofta märks det inte förrän någon undrar varför data saknas.

Det sista problemet är precis det heartbeat-monitoring är byggt för att lösa: istället för att bara lita på att webhooks alltid kommer fram, bevakar du att din endpoint faktiskt tar emot trafik regelbundet, och får ett larm om den tystnar. QRE8 Watchdog stödjer den här typen av push-baserad övervakning för webhook- och cron-integrationer.