Receive real-time notifications when events occur in Dodo Payments. Automate workflows and keep your systems synchronized with instant event delivery.
Webhooks provide real-time notifications when specific events occur in your Dodo Payments account. Use webhooks to automate workflows, update your database, send notifications, and keep your systems synchronized.
Our webhook implementation follows the Standard Webhooks specification, ensuring compatibility with industry best practices and existing webhook libraries.
Dodo Payments webbportal för webhooks har byggts om med en inbyggd dashboardupplevelse. Dina befintliga endpoints, signeringshemligheter, signaturverifiering, händelsenamn och webhook-payloads är oförändrade. Inget integrationsarbete behövs.
Här finns funktionerna.
Under Developer → Webhooks — flikarna Endpoints, Event catalog, Logs, Activity och Settings.
På en enskild endpoint — fliken Overview, med leveransstatistik, signeringshemligheten och Replay history, samt flikarna Testing och Advanced och åtgärder för massomspelning.
På ett meddelande — öppnas från fliken Logs, där varje leveransförsök kan spelas upp separat utan att endpointen behöver öppnas.
1
Access Webhook Settings
Gå till Dodo Payments Dashboard och öppna Developer → Webhooks.
2
Create Webhook Endpoint
Klicka på Add endpoint för att öppna sidopanelen för att skapa en endpoint.
3
Enter Endpoint URL or Choose Integration
Ange URL:en där du vill ta emot webhook-händelser, eller välj en integrationsanslutning för att dirigera händelser till en tredjepartstjänst (Slack, Discord, Zapier, Resend med flera).
4
Select Events to Receive
Välj de specifika händelser som endpointen ska lyssna efter. Händelserna är organiserade i ett sökbart träd, grupperade efter resurs. Du kan välja enskilda händelser eller en överordnad resurs för att ta emot alla relaterade händelser.
Endast valda händelser utlöser webhooks till endpointen, vilket hjälper dig att undvika onödig trafik och bearbetning.
5
Create Endpoint
Klicka på Create endpoint för att spara konfigurationen.
6
Get Secret Key
Din webhook-signeringstext visas på endpointens flik Overview. Du använder den för att verifiera äktheten hos mottagna webhooks.
Förvara din webhook-hemlighet säkert och exponera den aldrig i klientkod eller offentliga kodarkiv.
7
Rotate Secret (Optional)
Vid behov kan du rotera din webhook-hemlighet för förbättrad säkerhet. Klicka på Rotate secret bredvid hemligheten på fliken Overview.
När du roterar hemligheten upphör den gamla att gälla och ersätts av en ny. Den gamla hemligheten är endast giltig under de följande 24 timmarna. Därefter misslyckas verifiering med den gamla hemligheten.
Rotera hemligheten regelbundet eller omedelbart om du misstänker att den nuvarande hemligheten har röjts.
I stället för att bygga en egen webhook-mottagare kan du dirigera webhook-händelser direkt till tredjepartstjänster med hjälp av integrationsanslutningar. Då behöver du inte skriva och underhålla egna webhook-hanterare för populära plattformar.
En anslutning innehåller en transformering som omvandlar Dodo Payments-händelsen till det format som destinationen förväntar sig. Vilka uppgifter du behöver ange beror på destinationen:
Anslutningstyp
Det du anger
Destinationer
Incoming webhook URL
En webhook-URL som du skapar i leverantörens egen dashboard. Ingen API-nyckel.
Anslutningsväljaren i dashboarden visar hela uppsättningen som för närvarande är tillgänglig för ditt företag. Se därför tabellen ovan som destinationerna med stegvisa installationsinstruktioner, inte som en uttömmande lista. Se External Integrations för information om vad varje destination kan göra när händelserna når den.
Välj en anslutning när du skapar eller redigerar en endpoint. Sidopanelen visar installationsinstruktioner för destinationen — till exempel hur du skapar en inkommande webhook-URL i Slack eller var du hittar din Resend API-nyckel. Innan du sparar kör du ett test av anslutningens transformering för att bekräfta att händelsen konverteras korrekt för destinationen.
Använd en anslutning för att nå en destination som stöds utan att skriva kod. Om du behöver anpassad logik använder du en standardendpoint med en transformering i stället.
Du kan konfigurera vilka specifika händelser varje webhook-endpoint ska ta emot.
1
Navigate to Webhook Endpoints
Gå till Dodo Payments Dashboard och öppna Developer → Webhooks.
2
Select Your Endpoint
Klicka på webhook-endpointen som du vill konfigurera.
3
Open Event Configuration
Klicka på Edit för att öppna sidopanelen för endpointkonfiguration.
4
Browse Event Types
Väljaren för händelsetyp visar alla tillgängliga webhook-händelser i ett sökbart träd, grupperade efter resurs (t.ex. payment, subscription, dispute). Använd sökfältet för att snabbt hitta specifika händelser efter namn eller nyckelord.
5
Select Events
Markera rutorna bredvid händelserna du vill ta emot. Du kan:
Välja enskilda händelser (t.ex. payment.succeeded, payment.failed)
Välja en överordnad resurs för att ta emot alla relaterade händelser
Kombinera specifika händelser efter behov
6
Save Configuration
Klicka på Save för att tillämpa ändringarna, eller på Cancel för att ignorera dem.
Om du avmarkerar alla händelser tar webhook-endpointen inte emot några aviseringar. Se till att välja åtminstone de händelser som programmet behöver för att fungera korrekt.
Gå till Developer → Webhooks och öppna fliken Event catalog. Där listas alla händelsetyper som Dodo Payments kan skicka, så att du kan se vad som är tillgängligt innan du prenumererar en endpoint på händelsen. Välj en händelse för att se dess schema och en exempelpayload — det snabbaste sättet att kontrollera formatet på ett fält du planerar att läsa.
Webhook Events Guide
Bläddra bland samma händelser som referensdokumentation, grupperade efter resurs.
Webhooks har ett 15 sekunder långt tidsfönster för både anslutnings- och läsoperationer. Se till att endpointen svarar snabbt för att undvika tidsgränser.
Bearbeta webhooks asynkront genom att omedelbart bekräfta mottagandet med en 200-statuskod och sedan hantera den faktiska bearbetningen i bakgrunden.
Om en webhook-leverans misslyckas försöker Dodo Payments automatiskt igen med exponentiell backoff för att förhindra att systemet överbelastas.
Försök
Fördröjning
Beskrivning
1
Omedelbart
Det första nya försöket sker direkt
2
5 sekunder
Det andra försöket sker efter en kort fördröjning
3
5 minuter
Det tredje försöket använder en längre backoff
4
30 minuter
Det fjärde försöket fortsätter backoffen
5
2 timmar
Det femte försöket har en utökad fördröjning
6
5 timmar
Det sjätte försöket har en längre fördröjning
7
10 timmar
Det sjunde försöket har maximal fördröjning
8
10 timmar
Sista försöket – webhooken markeras som misslyckad om det inte lyckas
Högst 8 nya försök per webhook-händelse. Om en webhook till exempel misslyckas tre gånger innan den lyckas tar den totala leveransen cirka 35 minuter och 5 sekunder från det första försöket.
Använd Dodo Payments-dashboarden för att när som helst försöka leverera enskilda meddelanden igen eller massåterställa alla misslyckade meddelanden.
Varje webhook-händelse innehåller en unik webhook-id-header. Använd denna identifierare för att implementera idempotens och förhindra dubbel bearbetning.
// Example: Storing webhook IDs to prevent duplicate processingconst processedWebhooks = new Set();app.post('/webhook', (req, res) => { const webhookId = req.headers['webhook-id']; if (processedWebhooks.has(webhookId)) { return res.status(200).json({ received: true }); } processedWebhooks.add(webhookId); // Process the webhook...});
Implementera alltid idempotenskontroller. På grund av nya försök kan du ta emot samma händelse flera gånger.
Webhook-händelser kan komma i fel ordning på grund av nya försök eller nätverksförhållanden. Utforma systemet så att det kan hantera händelser i valfri ordning.
Du tar emot den senaste payloaden vid leveranstillfället, oavsett när webhook-händelsen ursprungligen skapades.
Varje webhook-begäran innehåller en webhook-signature-header, en HMAC SHA256-signatur av webhook-payloaden och tidsstämpeln, signerad med din hemliga nyckel.
Om du inte använder ett SDK kan du verifiera signaturer själv enligt specifikationen Standard Webhooks:
Skapa det signerade meddelandet genom att sammanfoga webhook-id, webhook-timestamp och den exakta råa, strängifierade payload, separerade med punkter (.).
Beräkna HMAC SHA256 för strängen med din webhook-hemlighet från Dashboard.
Jämför den beräknade signaturen med webhook-signature-headern. Om de matchar är webhooken äkta.
Signaturverifiering är det rekommenderade sättet att autentisera en webhook. Den bevisar att begäran signerades med din webhook-hemlighet, vilket en kontroll på nätverksnivå inte kan göra.Webhook-leveranser skickas från en pool med käll-IP-adresser som tillhör vår leveransinfrastruktur. Poolen ändras då och då, så betrakta adresserna som operativ information snarare än en fast egenskap hos integrationen.
Använd inte en allowlist för käll-IP som autentiseringsmekanism. En allowlist visar bara var en begäran kom ifrån, inte att den är äkta eller oförändrad — verifiera webhook-signature-headern för varje begäran, enligt beskrivningen i Verifiera signaturer.
Om din infrastruktur ligger bakom en brandvägg som kräver en explicit allowlist bör du tänka på följande:
Hårdkoda inte adresser permanent. Intervall läggs till och tas bort över tid, och en inaktuell regel blockerar leveranser utan någon tydlig indikation.
Begär de aktuella intervallen från support@dodopayments.com innan du låser en brandvägg, så att du använder en uppdaterad lista.
Håll utkik efter ändringsmeddelanden. När leveransadresser ändras meddelar vi berörda merchants via e-post — tillämpa uppdateringarna före det angivna datumet för att undvika uteblivna leveranser.
Behåll signaturverifiering aktiverad oavsett vilka nätverksregler du lägger till.
På serverless- och hanterade hostingplattformar är inkommande IP-filtrering ofta otillgänglig eller opraktisk att underhålla. Signaturverifiering är rätt kontroll i dessa miljöer, och ingen allowlist krävs.
En blockerad leverans behandlas som alla andra fel och görs om enligt schemat som beskrivs i Automatiska omförsök. Om brandväggsregler gjorde att leveranser misslyckades kan du skicka dem igen när reglerna har åtgärdats — se Spela upp och återställ meddelanden.
Fliken Testing skickar en exempelpayload till denna endpoint så att du kan verifiera din mottagare.
1
Select Event Type
Använd Select an event type för att välja händelsen du vill testa, till exempel payment.succeeded eller payment.failed.
2
Send Example
Klicka på Send example. Exempelpayloaden levereras till din endpoint-URL precis som en riktig händelse och signeras på samma sätt.
Misslyckade meddelanden som skickas från fliken Testing görs inte om. Använd den för att verifiera din mottagare, inte för att testa omförsöksschemat.
3
Check Your Endpoint
Fliken registrerar när Last example sent skickades. Bekräfta att händelsen kom fram, att signaturverifieringen lyckades och att du returnerade en 2xx-statuskod.
Testa din webhook-handler noggrant med dashboardens testgränssnitt innan du bearbetar produktionshändelser. Det hjälper dig att identifiera och åtgärda problem tidigt.
Vidarebefordra riktiga webhook-händelser från ditt konto i testläge till din lokala utvecklingsserver i realtid:
dodo wh listen
CLI öppnar en WebSocket-anslutning till Dodo Payments och vidarebefordrar varje webhook-händelse till din lokala endpoint (t.ex. http://localhost:3000/webhook) samtidigt som alla headers bevaras, inklusive signaturheaders för verifieringstestning.
Lyssnaren fungerar endast med API-nycklar i test mode. Kör dodo login och välj Test Mode innan du använder detta kommando.
Skicka simulerade webhook-payloads till valfri endpoint utan att skapa riktiga transaktioner:
dodo wh trigger
Med detta interaktiva verktyg kan du välja en händelsetyp och skicka en realistisk simulerad payload till din endpoint. Det körs i en loop så att du kan testa flera händelser i samma session.Trigger-kommandot omfattar alla 47 händelsetyper som Dodo Payments levererar, inklusive familjerna subscription, payment, refund, dispute, license key, payout, credit, abandoned checkout, dunning och entitlement grant — se Supported Webhook Events för den exakta listan.
Simulerade webhook-payloads från dodo wh trigger är inte signerade. Använd unsafe_unwrap() i stället för unwrap() i din webhook-handler, endast under testning.
CLI Webhook Testing Docs
Se den fullständiga dokumentationen om webhook-testning med CLI
Lägg till anpassade HTTP-headers i alla webhook-begäranden som skickas till din endpoint. Detta är användbart för autentisering, routing eller för att lägga till metadata.
1
Add Headers
I avsnittet “Custom Headers” anger du en Key och ett Value för varje anpassad header.
2
Add Multiple Headers
Klicka på knappen + för att lägga till fler anpassade headers vid behov.
Dina anpassade headers inkluderas i alla webhook-begäranden till denna endpoint.
Fliken Logs ger omfattande insyn i statusen för dina webhook-leveranser, så att du effektivt kan övervaka, felsöka och hantera webhook-händelser.
1
Navigate to Logs Tab
Gå till Developer → Webhooks och öppna fliken Logs.
2
Browse Delivery History
Visa en tabell över alla webhook-leveransförsök med kolumnerna Event type, Message ID, Event ID, Sent at, Attempted at, Response code och Duration.
3
Search and Filter
Använd sökfältet för att hitta specifika meddelanden efter ID eller händelsetyp. Filtrera efter status (Succeeded, Failed, Pending osv.) för att fokusera på de händelser du behöver undersöka.
4
View Message Details
Klicka på ett meddelande för att öppna meddelandets detaljsida, som visar:
Den fullständiga webhook-payloaden
Varje leveransförsök med svarskod och varaktighet
Tidsstämpeln för varje försök
Eventuella felmeddelanden från din endpoint
Varje försök har åtgärden Replay, så att du kan skicka just det meddelandet igen utan att lämna sidan.
Gå till Developer → Webhooks och öppna fliken Activity för att se leveransprestandan för alla dina endpoints.Delivery activity visar försök över tid, grupperade som Attempts per 5 minutes, Attempts per hour eller Attempts per day beroende på tidsfönstret. Varje stapel delas upp efter resultat, och när du håller pekaren över ett segment visas status, antalet försök och dess andel av totalen. För en endpoint sammanfattar Delivery stats (last 24h) på fliken Overview samma information för det senaste dygnet.
Kolumnen Error rate (24h) på fliken Endpoints visar direkt vilka endpoints som behöver åtgärdas, innan du öppnar någon av dem.
Öppna endpointen från Developer → Webhooks. Tre lägen är tillgängliga och vart och ett gäller endast den endpointen. Intervallet du anger beror på läget:
Läge
Vad det gör
Vad du anger
Recover failed messages
Spelar upp varje meddelande till denna endpoint som misslyckades.
En startpunkt: 8 hours ago, Yesterday, 3 days ago, Last week eller 2 weeks ago
Replay missing messages
Spelar upp meddelanden som aldrig skickades till denna endpoint, till exempel efter att du prenumererat på en ny händelsetyp.
Samma startpunkter
Bulk replay messages
Spelar upp meddelanden som matchar de filter du väljer, inklusive meddelanden som redan levererats utan fel.
Gränserna Since och Until, som som standard omfattar de senaste två veckorna, samt valfria händelsetyper, kanal eller tagg
1
Open More Actions
Öppna More actions på endpointen och välj ett av de tre lägena ovan.
2
Set the Range
Fyll i det intervall som läget efterfrågar, enligt tabellen.
3
Start the Run
Klicka på Recover eller Replay, beroende på vilket läge du valde.
Varje körning visas under Replay history på endpointens flik Overview, tillsammans med läge, tidsintervall, status och antalet omskickade meddelanden.
Redo att distribuera din webhook-handler till produktion? Vi tillhandahåller plattformsspecifika guider som hjälper dig att distribuera webhooks till populära molnleverantörer med bästa praxis för varje plattform.
Vercel
Distribuera webhooks till Vercel med serverless-funktioner
Cloudflare Workers
Kör webhooks på Cloudflares edge-nätverk
Supabase Edge Functions
Integrera webhooks med Supabase
Netlify Functions
Distribuera webhooks som Netlify-serverless-funktioner
Varje plattformsguide innehåller miljökonfiguration, signaturverifiering och distributionssteg som är specifika för leverantören.