Du försöker testa ”riktiga” webhooks, men din app kör på localhost. Så du slutar med att öppna portar, pilla med routrar eller spinna upp en tillfällig server du inte litar på. Det går långsamt. Det är skört.
Det här är den typen av smärta som drabbar en utvecklare mitt i en build, men byråteam och drift känner av det också när kundintegrationer snabbt behöver bevis. Med den här automatiseringen för webhook Slack testing kan du ta emot webhook-händelser i produktionsklass publikt och vidarebefordra dem säkert till ditt lokala n8n-flöde.
Nedan ser du hur flödet beter sig, vad det automatiserar och de praktiska uppsättningsdelarna som gör det pålitligt för upprepad testning.
Så fungerar automatiseringen
Hela n8n-flödet, från trigger till slutresultat:
n8n Workflow Template: webhook.site + Slack för lokal webhooktestning
flowchart LR
subgraph sg0["Schedule Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Get Auth Token"]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Unprocessed Requests"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Get Latest Requests"]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>POST to n8n"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge"]
n6@{ icon: "mdi:swap-vertical", form: "rounded", label: "Local Webhook Address", pos: "b", h: 48 }
n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Latest Update Time"]
n8@{ icon: "mdi:cog", form: "rounded", label: "Store Auth Token", pos: "b", h: 48 }
n9@{ icon: "mdi:cog", form: "rounded", label: "Store Last Processed", pos: "b", h: 48 }
n10@{ icon: "mdi:cog", form: "rounded", label: "Retrieve Auth Token", pos: "b", h: 48 }
n11@{ icon: "mdi:cog", form: "rounded", label: "Retrieve Last Processed", pos: "b", h: 48 }
n12@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If Auth Token Exists", pos: "b", h: 48 }
n5 --> n2
n1 --> n8
n0 --> n6
n0 --> n11
n8 --> n3
n7 --> n9
n3 --> n5
n10 --> n12
n12 --> n3
n12 --> n1
n9 --> n4
n2 --> n7
n6 --> n10
n11 --> n5
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n12 decision
class n1,n3,n4 api
class n2,n7 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3,n4,n5,n7 customIcon
Problemet: testa webhooks från publika webben mot localhost
Webhook-testning låter enkelt tills du gör det under verkliga förhållanden. Din leverantör kan bara skicka till en publik URL, men din kod kör lokalt, och att exponera din maskin är både en säkerhets- och nätverksmässig huvudvärk. Även om du får till en tunnel slåss du fortfarande med instabila anslutningar, URL:er som ändras och problemet ”har vi redan processat den här händelsen?” som orsakar dubbla körningar och förvirring. Och så har du kontextbytena: kopiera payloads, köra om tester, scrolla loggar, upprepa. Det som borde vara snabb validering blir en hel eftermiddag.
Det växer snabbt. Här är var det vanligtvis faller isär i praktiken.
- Du slösar cirka 1–2 timmar per integration bara på att få en stabil publik-till-lokal väg att fungera.
- Dubbla webhook-leveranser skapar ”spökbuggar” eftersom ditt lokala flöde bearbetar samma händelse två gånger.
- Tokens och auth-headers hanteras fel, så tester lyckas en gång och misslyckas sedan när du kör om dem.
- När något fallerar får du ofta veta det för sent eftersom du inte bevakar körningar varje minut.
Lösningen: fånga på webhook.site, vidarebefordra till din lokala webhook
Det här flödet ger dig ett stabilt, repeterbart sätt att testa riktiga webhooks mot en lokal n8n-instans utan att exponera din dev-server. Det startar på schema, kontrollerar (och lagrar) autentiseringstoken som behövs för att prata med webhook.site och hämtar sedan de senaste förfrågningarna som träffat din webhook.site-URL. Därefter filtrerar det bort allt du redan har behandlat genom att jämföra tidsstämplar och spara det senaste ”senast behandlad”-värdet till nästa gång. Till sist vidarebefordrar det endast nya webhook-payloads till din lokala n8n-webhookadress, vilket gör att ditt lokala flöde kan bete sig som om det tar emot publika webhooks direkt.
Flödet startar när den schemalagda triggern kör. Därefter säkerställer det att webhook.site-auth finns tillgänglig, hämtar senaste webhook-förfrågningar och deduplicerar dem med en sparad tidsstämpel. I slutet skickar det vidare nya händelser till din localhost-webhookendpoint så att din lokala build kan svara normalt.
Vad du får: automatisering vs resultat
| Vad det här flödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du validerar Stripe-liknande händelser från en leverantör som bara stödjer publika webhook-URL:er. Manuell väg kan du lägga cirka 30 minuter på att sätta upp en tunnel, ytterligare 30 minuter på att konfigurera om den efter en omstart och sedan 20 minuter på att jaga dubbletter i loggar. Det är ungefär 1–2 timmar innan du ens fixar den faktiska buggen. Med det här flödet pekar du leverantören mot din webhook.site-URL en gång, och sedan hämtar den schemalagda körningen nya händelser och vidarebefordrar dem till localhost i bakgrunden. Du väntar mest på exekveringstid, inte på setup-arbete.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för egen hosting om du föredrar det (Hostinger fungerar bra)
- webhook.site för att ta emot publika webhook-förfrågningar
- Slack för att varna dig när vidarebefordringar misslyckas
- webhook.site API-token (hämta den i webhook.site-kontots inställningar)
Svårighetsnivå: Medel. Du klistrar in URL:er/tokens och förstår vad en webhook-endpoint är.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En schemalagd kontroll startar allt. n8n kör på en timer så att du kan polla webhook.site regelbundet utan att ha en webbläsarflik öppen hela dagen.
Din lokala webhookadress sätts. Flödet laddar URL:en till din localhost-webhook (den som ditt lokala n8n-flöde exponerar) så att destinationen för vidarebefordran är konsekvent.
Auth- och dedupe-logik kör tyst. Det laddar den sparade webhook.site-tokenen från en nyckel-värde-lagring, hämtar förfrågningar och filtrerar sedan till endast de som är nyare än din senast behandlade tidsstämpel. Det är ärligt talat det som gör den användbar i vardagen, eftersom du inte konstant behöver hantera repetitioner.
Nya händelser skickas vidare till localhost. Flödet skickar den råa payloaden till din lokala webhook-endpoint via HTTP och sparar sedan den senaste tidsstämpeln så att nästa körning bara skickar vidare leveranser som faktiskt är nya.
Du kan enkelt justera pollningsschemat så att det kör snabbare (eller långsammare) efter behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera den schemalagda triggern
Ställ in schemat som driver arbetsflödet så att det kontrollerar nya webhook.site-förfrågningar med ett regelbundet intervall.
- Lägg till och öppna Scheduled Automation Start.
- Ställ in regelintervallet på Seconds och sätt Seconds Interval till
10. - Bekräfta att Scheduled Automation Start skickar utdata parallellt till både Define Local Webhook och Load Last Processed.
Steg 2: Anslut webhook och lokal tillståndslagring
Definiera webhook-URL:en för målet och läs in cachade värden för autentisering och senast behandlad tidsstämpel.
- Öppna Define Local Webhook och sätt värdet webhook till
http://localhost:5678/webhook/[YOUR_ID]. - Öppna Load Auth Token och sätt Key till
auth_token, File Name tillsavefileoch Operation tillread. - Öppna Load Last Processed och sätt Key till
last_processed, File Name tillsavefileoch Operation tillread.
[YOUR_ID] i Define Local Webhook kommer Relay to Local Webhook att posta till en ogiltig URL.Steg 3: Sätt upp logik för hämtning av token
Använd kontrollen för om token finns för att antingen återanvända en befintlig webhook.site-token eller hämta och spara en ny.
- Öppna Check Token Presence och bekräfta att villkoret använder
{{ $json.value }}med operatorn exists. - Öppna Fetch Auth Token och sätt URL till
https://webhook.site/tokenoch Method tillPOST. - Öppna Persist Auth Token och sätt Key till
auth_token, Value till{{ $json.uuid }}och File Name tillsavefile. - Öppna Retrieve Recent Requests och sätt URL till
=https://webhook.site/token/{{ $json.value }}/requests.
Steg 4: Konfigurera logik för sammanslagning och filtrering
Slå ihop den senaste listan med förfrågningar med den senast behandlade tidsstämpeln och filtrera därefter till endast nya POST-förfrågningar.
- Öppna Combine Streams och sätt Mode till
combineoch Combine By tillcombineByPosition. - Öppna Filter New Requests och klistra in hela JavaScript-koden från arbetsflödet, inklusive
filter_methodsatt tillPOSToch logiken för konvertering av datum/tid. - Bekräfta körordningen: Retrieve Recent Requests och Load Last Processed går in i Combine Streams, och därefter Filter New Requests.
created_at eller method kommer filterlogiken i Filter New Requests att returnera en tom mängd.Steg 5: Spara den senaste tidsstämpeln och vidarebefordra payloaden
Beräkna den senaste tidsstämpeln från de filtrerade förfrågningarna, spara den och vidarebefordra sedan varje förfrågan till er lokala webhook.
- Öppna Compute Latest Timestamp och sätt JavaScript till
var datetimes = $('Filter New Requests').all().map(x=>x.json.created_at) return {last_time: Math.max(...datetimes)}. - Öppna Save Last Processed och sätt Key till
last_processed, Value till{{ $json.last_time }}och File Name tillsavefile. - Öppna Relay to Local Webhook och sätt URL till
{{ $('Define Local Webhook').first().json.webhook }}. - I Relay to Local Webhook, sätt Body till
{{ $('Filter New Requests').item.json.content }}, Method tillPOST, Send Body till On, Content Type tillrawoch Raw Content Type till=application/json.
Steg 6: Testa och aktivera ert arbetsflöde
Kör ett manuellt test för att bekräfta att data flödar genom varje gren och att er lokala webhook tar emot nya POST-förfrågningar.
- Klicka på Execute Workflow och bekräfta att Scheduled Automation Start triggar både Define Local Webhook och Load Last Processed parallellt.
- Skicka en POST-förfrågan till er webhook.site-endpoint och bekräfta att den syns i Retrieve Recent Requests och passerar genom Filter New Requests.
- Verifiera att Save Last Processed uppdaterar nyckeln
last_processedoch att Relay to Local Webhook postar JSON till er lokala webhook-URL. - Aktivera arbetsflödet med reglaget Active för att köra enligt schema.
Vanliga fallgropar
- webhook.site-credentials kan gå ut eller kräva specifika behörigheter. Om det strular, kontrollera först din sparade token i n8n-noden för nyckel-värde-lagring.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströms noder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in ert varumärkets tonalitet tidigt, annars kommer du redigera utdata i all evighet.
Vanliga frågor
Cirka 30 minuter om du redan har din lokala webhook-URL och webhook.site-token.
Nej. Du kopplar in credentials, klistrar in din lokala webhookadress och aktiverar flödet.
Ja. n8n har ett gratis alternativ för egen hosting och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volym. Du behöver också räkna med webhook.site-kostnader om din kontonivå begränsar historiken för förfrågningar.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen hosting på en VPS. För egen hosting är Hostinger VPS prisvärd och hanterar n8n bra. Egen hosting ger dig obegränsat antal körningar men kräver grundläggande serverhantering.
Ja, men. Du kan minska schemaintervallet så att det kontrollerar webhook.site oftare, och du kan även justera ”senast behandlad”-logiken till att använda ett event-ID istället för tidsstämplar om din leverantör skickar ett sådant. Vissa team vidarebefordrar till olika lokala endpoints genom att ändra fältet ”Define Local Webhook”. Om du vill ha Slack-varningar vid fel, lägg till ett Slack-meddelandesteg efter vidarebefordran när HTTP-svaret inte är lyckat.
Oftast handlar det om en utgången eller saknad token i noden för nyckel-värde-lagring. Skapa en ny webhook.site-token, uppdatera sedan det sparade värdet och kör schemat en gång. Kontrollera också att flödet läser rätt tokenfält, eftersom ett tomt värde skickar det till grenen ”fetch token” och ändå kan misslyckas om den uppströms förfrågan blockeras. Rate limits kan också dyka upp om du pollar väldigt aggressivt.
Många, inom rimliga gränser. Den största begränsningen är hur många förfrågningar webhook.site håller tillgängliga för dig att hämta, plus dina n8n-exekveringsgränser om du kör en cloud-plan. Om du hostar själv beror exekveringsvolymen mest på serverstorlek och hur ofta du pollar. För typisk testning (dussintals till några hundra händelser) flyter det på.
För just den här uppgiften är n8n oftast bättre, eftersom du kan köra lokalt, lagra tillstånd som ”senast behandlad” utan fulhack och lägga till branchlogik utan att betala per väg. Zapier och Make kan absolut fånga webhooks, men de är inte byggda för att vidarebefordra in i en lokal dev-miljö på ett kontrollerat sätt. En annan praktisk fördel är portabilitet: du kan exportera flödet och dela det mellan kundprojekt. Om ditt team vill ha Slack-varningar när något går sönder kan du lägga in dem exakt där felen uppstår. Prata med en automationsexpert om du vill ha hjälp att välja den enklaste vägen.
När detta väl rullar slutar webhook-testning att vara ett ”setup-projekt” och blir det det ska vara: snabb validering. Sätt upp det en gång och fortsätt bygga.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.