Hva er en webhook? Slik varsler apper hverandre

En webhook er en automatisk melding som én tjeneste sender til appen din i det øyeblikket noe skjer. Når en kundes betaling går gjennom, sender Stripe en webhook til en adresse i appen din som sier «betaling gjennomført, her er detaljene», og appen din reagerer — markerer bestillingen som betalt, sender kvittering, låser opp kontoen. Kort sagt: et API er at appen din stiller et spørsmål til en annen tjeneste; en webhook er at den andre tjenesten kaller appen din for å fortelle noe.

Hvorfor det betyr noe når du bygger med AI

Så snart appen din tar imot betalinger, mottar skjemainnsendinger fra et annet verktøy, eller kobler seg til tjenester som GitHub, Shopify eller en kalender, vil du støte på webhooks. De er vanligvis den riktige måten å vite at noe har skjedd på — men det er også der apper bygget med AI oftest er subtilt feil:

• Endepunktet aksepterer enhver forespørsel, så hvem som helst kan forfalske en «betaling gjennomført»-hendelse.
• Appen gir tilgang på betalingsbekreftelsessiden i stedet for i webhooken, slik at folk som lukker fanen tidlig aldri får det de betalte for, og folk som finner suksess-URL-en får det gratis.
• Den samme hendelsen kommer to ganger, og kunden får to bestillinger eller to e-poster.

Å kjenne til hvordan webhooks fungerer, lar deg be om beskyttelsene på forhånd.

En hverdagslig sammenligning: en leveringssms

Du kan finne ut om pakken din er kommet på to måter. Du kan gå til ytterdøren hvert tiende minutt for å sjekke (det er polling — appen din kaller et API gjentatte ganger for å spørre «noe nytt?»). Eller budet kan sende deg en sms når den er levert (det er en webhook).

Smsen er klart bedre — så lenge du kan stole på den. Hvis hvem som helst kunne sende deg en «pakke levert»-melding, ville du ønske en måte å vite at den virkelig kom fra budet. Og hvis telefonen var av da smsen kom, ville du ønske at budet prøvde igjen senere. Disse to hensynene — verifisering og nye forsøk — er det meste av det som gjør webhooks kompliserte.

Slik fungerer en webhook, steg for steg

1. Du oppretter et endepunkt i appens backend: en URL som https://dinapp.no/webhooks/stripe som tar imot POST-forespørsler.
2. Du registrerer URL-en hos leverandøren og velger hvilke hendelser du vil ha (for eksempel «utsjekk fullført» og «abonnement kansellert»).
3. Leverandøren gir deg en signeringshemmelighet. Du lagrer den som en hemmelighet på serveren din — se miljøvariabler og hemmeligheter.
4. En hendelse skjer. Leverandøren sender en HTTP-forespørsel til URL-en din med en JSON-kropp som beskriver den, pluss en signaturheader.
5. Appen din verifiserer signaturen, registrerer hendelses-ID-en, svarer raskt med en suksesskode (200), og utfører deretter jobben.
6. Hvis appen din ikke svarer med suksess, prøver mange leverandører igjen senere.

Signaturer

En signatur beviser at forespørselen kom fra leverandøren og ikke er endret. Stripe beregner for eksempel en HMAC (en slags nøkkelbasert fingeravtrykk) med SHA-256 over forespørselens kropp og et tidsstempel, ved hjelp av signeringshemmeligheten, og sender den i en Stripe-Signature-header. Appen din gjør den samme beregningen med sin kopi av hemmeligheten; hvis resultatene stemmer, er forespørselen ekte. Fordi tidsstemplet også er signert, kan du avvise gamle forespørsler som noen har tatt opp og spiller av senere — Stripes biblioteker bruker en toleranse på fem minutter som standard, ifølge dokumentasjonen per september 2026.

En praktisk detalj: signaturen beregnes på den rå forespørselskroppen. Hvis rammeverket ditt parser og formaterer JSON på nytt før du verifiserer, feiler sjekken. Dette er en svært vanlig feil.

Nye forsøk, duplikater og rekkefølge

Leverandørene er ulike, så sjekk hver enkelt sin dokumentasjon. Per september 2026:

Stripes dokumentasjon sier også at hendelser ikke garantert kommer i den rekkefølgen de skjedde, og at samme hendelse av og til kan komme mer enn én gang, så den anbefaler å spore hendelses-ID-er.

Den generelle lærdommen gjelder for alle leverandører: hendelser kan komme sent, mer enn én gang og i feil rekkefølge. Behandleren din bør være idempotent — å behandle samme hendelse to ganger gir samme effekt som å behandle den én gang.

Et eksempel: å låse opp et betalt kurs

Du selger et nettkurs. En student klikker Kjøp, betaler på Stripes hostede betalingsside, og sendes tilbake til nettstedet ditt.

Den skjøre måten: «takk»-siden låser opp kurset. Hvis studenten lukker nettleseren under videresendingen, har de betalt, men har ingen tilgang. Hvis noen gjetter takk-URL-en, får de tilgang uten å betale.

Webhook-måten:

1. Når Stripe bekrefter betalingen, sender den en checkout.session.completed-hendelse til /webhooks/stripe.
2. Backenden din verifiserer signaturen med signeringshemmeligheten. Hvis det feiler, svarer den 400 og gjør ingenting.
3. Den sjekker om den hendelses-ID-en allerede er behandlet. Hvis ja, svarer den 200 og stopper.
4. Den lagrer hendelses-ID-en, svarer 200, og gir deretter studenten tilgang og sender en velkomst-e-post.
5. Takk-siden sier bare «Betaling mottatt — kurset ditt vises om et øyeblikk» og sjekker studentens tilgangsstatus.

Senere, hvis et abonnement kanselleres eller et kort feiler, forteller andre webhook-hendelser appen din om å fjerne eller pause tilgang. Slik holder abonnementsprodukter seg synkronisert med fakturering — se hva SaaS er og hvordan du legger til betalinger i appen din.

Viktige begreper

• Endepunkt: URL-en i appen din som tar imot webhooks.
• Hendelse / nyttelast: hva som skjedde, og dataene som beskriver det (vanligvis JSON).
• Signeringshemmelighet: den delte hemmeligheten som brukes til å verifisere signaturer.
• Idempotent: trygt å kjøre mer enn én gang med samme resultat.
• Polling: å gjentatte ganger spørre et API etter endringer i stedet for å vente på en webhook.
• Tunnel: et verktøy som gir en bærbar PC en midlertidig offentlig URL, slik at webhooks kan nå den under utvikling.

Vanlige feil og misforståelser

• Å ikke verifisere signaturer. Endepunkt-URL-en er ikke en hemmelighet. Verifisering er det som gjør forespørselen pålitelig.
• Å gjøre tregt arbeid før du svarer. Å sende e-poster eller generere PDF-er før du svarer kan føre til tidsavbrudd, som utløser nye forsøk, som gir duplikater.
• Å anta nøyaktig én gang, i rekkefølge. Registrer hendelses-ID-er, og stol ikke på ankomstrekkefølge.
• Å bruke en forhåndsvisnings-URL. Webhooks trenger en stabil, offentlig adresse. Private forhåndsvisninger og localhost kan ikke nås fra internett; bruk den publiserte URL-en din (eller en tunnel under testing).
• Å blande test- og live-hemmeligheter. Leverandører utsteder ofte ulike signeringshemmeligheter for test- og live-modus. Lagre begge og bruk riktig en.
• Å stole blindt på nyttelasten for viktige beslutninger. For handlinger med høy innsats er det fornuftig å hente siste tilstand fra leverandørens API etter at hendelsen er mottatt.

Hva du skal be AI-byggeren om

Legg til et POST /webhooks/stripe-endepunkt på serveren. Verifiser Stripe-signaturen ved hjelp av den rå forespørselskroppen og hemmeligheten STRIPE_WEBHOOK_SECRET. Avvis ugyldige signaturer med 400. Lagre hver hendelses-ID og hopp over hendelser som allerede er behandlet. Svar 200 raskt, og håndter deretter checkout.session.completed ved å markere bestillingen som betalt og sende kvitteringen. Logg hendelsestypen. Gi ikke tilgang fra betalingsbekreftelsessiden.

Test det deretter: send en testhendelse fra leverandørens dashbord, send den samme en gang til, og send en forespørsel med feil signatur. Bare den første skal endre noe.

Webhooks i Mythex

Mythex kjører ikke en egen webhook-tjeneste; du ber agenten legge til et webhook-endepunkt i appens egen backend, og peke leverandøren mot din publiserte URL, siden webhooks trenger en offentlig adresse. Signeringshemmeligheten legges i prosjektets hemmeligheter, og hvis du endrer den i en live-app, publiserer du på nytt. Dokumentasjonsoppskriften om håndtering av webhooks har en startprompt, og butikkmaler er et godt utgangspunkt for apper som tar betalinger.

Spørsmål