Vad är en webhook? Så meddelar appar varandra

En webhook är ett automatiskt meddelande som en tjänst skickar till din app i samma ögonblick som något händer. När en kunds betalning går igenom skickar Stripe en webhook till en adress i din app med texten "betalningen lyckades, här är detaljerna", och din app reagerar – markerar ordern som betald, skickar ett kvitto, låser upp kontot. Kort sagt: ett API är din app som ställer en fråga till en annan tjänst; en webhook är den andra tjänsten som ringer din app för att berätta något.

Varför det spelar roll när du bygger med AI

Så snart din app tar betalningar, tar emot formulärinskick från ett annat verktyg eller kopplar upp sig mot tjänster som GitHub, Shopify eller en kalender, stöter du på webhooks. De är oftast det rätta sättet att få veta att något har hänt – men det är också där AI-byggda appar oftast är subtilt fel:

• Slutpunkten accepterar vilken förfrågan som helst, så vem som helst kan förfalska en händelse "betalning lyckades".
• Appen ger åtkomst på betalningssidans redirect i stället för i webhooken, så personer som stänger fliken tidigt får aldrig det de betalat för, och personer som hittar framgångs-URL:en får det gratis.
• Samma händelse kommer två gånger och kunden får två ordrar eller två mejl.

Om du vet hur webhooks fungerar kan du be om skydden i förväg.

En vardaglig jämförelse: ett leveranssms

Du kan ta reda på om ditt paket har kommit på två sätt. Du kan gå till ytterdörren var tionde minut för att kolla (det kallas polling – din app anropar upprepade gånger ett API för att fråga "något nytt?"). Eller så kan budet skicka ett sms när paketet levererats (det är en webhook).

Smset är klart bättre – så länge du kan lita på det. Om vem som helst kunde skicka ett "paket levererat"-meddelande skulle du vilja ha något sätt att veta att det verkligen kom från budet. Och om din telefon var avstängd när smset kom skulle du vilja att budet försökte igen senare. Dessa två frågor – verifiering och återförsök – är de flesta av de knepiga delarna med webhooks.

Hur en webhook fungerar, steg för steg

1. Du skapar en slutpunkt i din apps backend: en URL som https://dinapp.se/webhooks/stripe som tar emot POST-förfrågningar.
2. Du registrerar URL:en hos leverantören och väljer vilka händelser du vill ha (till exempel "utcheckning slutförd" och "prenumeration avslutad").
3. Leverantören ger dig en signeringshemlighet. Du lagrar den som en hemlighet på din server – se miljövariabler och hemligheter.
4. En händelse inträffar. Leverantören skickar en HTTP-förfrågan till din URL med en JSON-kropp som beskriver den, plus en signaturheader.
5. Din app verifierar signaturen, registrerar händelse-ID:t, svarar snabbt med en lyckad kod (200) och utför sedan arbetet.
6. Om din app inte svarar med lyckat, försöker många leverantörer igen senare.

Signaturer

En signatur bevisar att förfrågan kom från leverantören och inte har ändrats. Stripe beräknar till exempel en HMAC (en sorts nyckelad fingeravtryck) med SHA-256 över förfrågans kropp och en tidsstämpel, med signeringshemligheten, och skickar den i headern Stripe-Signature. Din app gör samma beräkning med sin kopia av hemligheten; om resultaten stämmer är förfrågan äkta. Eftersom tidsstämpeln också är signerad kan du avvisa gamla förfrågningar som någon spelat in och spelar upp senare – Stripes bibliotek har enligt dess dokumentation per september 2026 en standardtolerans på fem minuter.

En praktisk detalj: signaturen beräknas på den råa förfrågningskroppen. Om ditt ramverk tolkar och formaterar om JSON innan du verifierar, misslyckas kontrollen. Det här är ett mycket vanligt fel.

Återförsök, dubbletter och ordning

Leverantörerna skiljer sig åt, så kontrollera varje dokumentation. Per september 2026:

Stripes dokumentation säger också att händelser inte garanteras komma i den ordning de inträffade, och att samma händelse ibland kan komma mer än en gång, så den rekommenderar att du spårar händelse-ID:n.

Den allmänna lärdomen gäller för alla leverantörer: händelser kan komma sent, mer än en gång och i fel ordning. Din hanterare bör vara idempotent – att bearbeta samma händelse två gånger ger samma effekt som att bearbeta den en gång.

Ett praktiskt exempel: att låsa upp en betald kurs

Du säljer en onlinekurs. En student klickar på Köp, betalar på Stripes hostade betalningssida och skickas tillbaka till din sajt.

Det ömtåliga sättet: "tack"-sidan låser upp kursen. Om studenten stänger webbläsaren under redirecten har hen betalat men saknar åtkomst. Om någon gissar tack-URL:en får hen åtkomst utan att betala.

Webhook-sättet:

1. När Stripe bekräftar betalningen skickar den en checkout.session.completed-händelse till /webhooks/stripe.
2. Din backend verifierar signaturen med signeringshemligheten. Om den misslyckas svarar den 400 och gör ingenting.
3. Den kontrollerar om det händelse-ID:t redan har bearbetats. Om ja svarar den 200 och stannar.
4. Den sparar händelse-ID:t, svarar 200 och ger sedan studenten åtkomst och skickar ett välkomstmejl.
5. Tack-sidan säger bara "Betalningen mottagen – din kurs dyker upp strax" och kontrollerar studentens åtkomststatus.

Senare, om en prenumeration avslutas eller ett kort nekas, säger andra webhook-händelser åt din app att ta bort eller pausa åtkomsten. Så håller prenumerationsprodukter sig synkade med fakturering – se vad SaaS är och hur du lägger till betalningar i din app.

Viktiga termer

• Slutpunkt (endpoint): URL:en i din app som tar emot webhooks.
• Händelse / payload: vad som hände, och datan som beskriver det (oftast JSON).
• Signeringshemlighet: den delade hemligheten som används för att verifiera signaturer.
• Idempotent: säker att köra mer än en gång med samma resultat.
• Polling: att upprepade gånger fråga ett API efter ändringar i stället för att vänta på en webhook.
• Tunnel: ett verktyg som ger en laptop en tillfällig publik URL så att webhooks kan nå den under utveckling.

Vanliga misstag och missuppfattningar

• Att inte verifiera signaturer. Slutpunkts-URL:en är inte en hemlighet. Verifieringen är det som gör förfrågan pålitlig.
• Att göra långsamt arbete innan du svarar. Att skicka mejl eller generera PDF:er före svaret kan orsaka timeouts, som utlöser återförsök, som orsakar dubbletter.
• Att anta exakt en gång, i ordning. Registrera händelse-ID:n och lita inte på ankomstordningen.
• Att använda en förhandsvisnings-URL. Webhooks behöver en stabil, publik adress. Privata förhandsvisningar och localhost går inte att nå från internet; använd din publicerade URL (eller en tunnel under testning).
• Att blanda test- och live-hemligheter. Leverantörer utfärdar ofta olika signeringshemligheter för test- och livelägen. Lagra båda och använd rätt.
• Att blint lita på payloaden för viktiga beslut. För åtgärder med höga insatser är det rimligt att hämta det senaste tillståndet från leverantörens API efter att du tagit emot händelsen.

Vad du ska be din AI-byggare om

Lägg till en POST /webhooks/stripe-slutpunkt på servern. Verifiera Stripe-signaturen med den råa förfrågningskroppen och hemligheten STRIPE_WEBHOOK_SECRET. Avvisa ogiltiga signaturer med 400. Spara varje händelse-ID och hoppa över händelser som redan bearbetats. Svara 200 snabbt, hantera sedan checkout.session.completed genom att markera ordern som betald och skicka kvittot. Logga händelsetypen. Ge inte åtkomst från betalningens framgångssida.

Testa sedan: skicka en testhändelse från leverantörens dashboard, skicka samma igen och skicka en förfrågan med fel signatur. Bara den första ska ändra något.

Webhooks i Mythex

Mythex kör ingen separat webhook-tjänst; du ber agenten lägga till en webhook-slutpunkt i din apps egna backend och pekar leverantören mot din publicerade URL, eftersom webhooks behöver en publik adress. Signeringshemligheten läggs i dina projekthemligheter, och om du ändrar den på en live-app publicerar du igen. Docs-receptet om hantering av webhooks har en startprompt, och butiksmallar är en bra utgångspunkt för appar som tar betalningar.

Frågor