Din webhook-endpoint gör exakt det du har sagt åt den att göra: ta emot förfrågningar. Problemet är att den inte kan skilja mellan din app och slumpmässig skräptrafik, så du får spamtriggers, brusiga loggar och arbetsflöden som körs när de inte ska.
Den här webhook key checks-automationen drabbar ops-folk först (de som städar upp incidenter), men marknadsförare som kör lead capture och byråägare som levererar automationer till kunder märker det också. Resultatet är enkelt: bara förfrågningar med en giltig x-api-key-header släpps igenom.
Du sätter upp en n8n-webhook som “gatekeeper”, testar den från Postman och returnerar ett tydligt 200- eller 401-svar så att dåliga anrop stoppas direkt.
Så fungerar den här automationen
Här är hela arbetsflödet du ska sätta upp:
n8n Workflow Template: Postman-webhooks: stoppa dåliga anrop med API-nyckelkontroll
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n1@{ icon: "mdi:swap-horizontal", form: "rounded", label: "API Key Identified", pos: "b", h: 48 }
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/webhook.dark.svg' width='40' height='40' /></div><br/>Respond to Webhook (success)"]
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/webhook.dark.svg' width='40' height='40' /></div><br/>Respond to Webhook (unauthor.."]
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/webhook.dark.svg' width='40' height='40' /></div><br/>Secured Webhook"]
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Check API Key"]
n5 --> n1
n4 --> n5
n1 --> n2
n1 --> n3
end
subgraph sg1["Flow 2"]
direction LR
n0@{ icon: "mdi:swap-vertical", form: "rounded", label: "Registered API Keys", pos: "b", h: 48 }
n6@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Find API Key", 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/webhook.dark.svg' width='40' height='40' /></div><br/>Get API Key"]
n8@{ icon: "mdi:swap-vertical", form: "rounded", label: "Split Out Users", pos: "b", h: 48 }
n7 --> n0
n8 --> n6
n0 --> n8
end
subgraph sg2["Flow 3"]
direction LR
n9["<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/>Test Secure Webhook"]
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 n1,n6 decision
class n2,n3,n4,n5,n7,n9 api
classDef customIcon fill:none,stroke:none
class n2,n3,n4,n5,n7,n9 customIcon
Varför det här spelar roll: otillförlitliga webhooks triggar riktigt arbete
Webhooks är smidiga eftersom de är öppna av design. Det är också därför de missbrukas. När en endpoint-URL läcker till webbläsarhistorik, ett delat dokument, en repo-snutt eller ett supportärende hos en leverantör kan den bombaderas med retries, skanningar och “vi testar och ser vad som händer”-förfrågningar. Varje träff kan skapa en lead, skicka ett mejl, skriva till en databas, pinga Slack eller väcka någon i ditt team. Och ärligt talat: du märker det oftast sent – efter att dubbletter har staplats, automationer känns opålitliga eller en kund frågar varför de fick tre bekräftelser.
Det eskalerar snabbt. Här är var det brukar fallera.
- Vem som helst som hittar webhook-URL:en kan trigga den, eftersom en URL i sig inte är autentisering.
- Manuell städning är långsam och stressig när dåliga förfrågningar skapar verkliga effekter längre ned, som mejl, uppgifter eller databasrader.
- Retries från legitima system ser ofta ut som spam, så det är svårt att filtrera utan en konsekvent “godkänd/underkänd”-regel.
- Om du inte returnerar ett tydligt 200- eller 401-svar fortsätter anropare att göra retries, vilket gör röran värre.
Det du bygger: en webhook-gatekeeper med API-nyckelvalidering
Det här arbetsflödet skapar en skyddad webhook-endpoint i n8n som bara behandlar förfrågningar som bär en giltig API-nyckel i x-api-key-headern. När en POST-förfrågan träffar din “Protected Webhook Entry” plockar n8n direkt ut header-värdet och kontrollerar det mot dina godkända nycklar. I stället för att exponera ditt nyckelregister direkt mot den publika endpointen gör arbetsflödet ett internt HTTP-anrop till en andra webhook som fungerar som en privat uppslagstjänst. Den uppslagningen returnerar användarposten när nyckeln matchar, och huvud-webhooken svarar antingen med en strukturerad “200 OK” (inklusive identifierat användar-ID) eller “401 Unauthorized” för ogiltiga nycklar. Dina automationer slutar köra på brus och du får förutsägbart beteende som du kan testa i Postman.
Arbetsflödet börjar med ett inkommande webhook-anrop. Sedan verifierar det x-api-key genom att anropa en intern “Key Lookup”-webhook som kontrollerar en registrerad nyckellista. Till sist returnerar det 200 eller 401 direkt, så att dåliga anrop aldrig når din faktiska affärslogik.
Det du bygger
| Det som automatiseras | Det du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att din webhook normalt startar ett arbetsflöde i 6 steg (skapa en lead, tagga en kontakt, skicka ett mejl, logga en rad, notifiera Slack och uppdatera en dashboard). När skräptrafik träffar den 20 gånger på en dag får du cirka 120 oönskade åtgärder plus efterarbete. Med det här arbetsflödet stoppas samma 20 anrop vid ytterdörren med ett 401 på några sekunder, och bara giltiga förfrågningar kör den riktiga automationen. Testning går snabbt också: cirka 2 minuter för att lägga till nycklar och skicka en Postman-förfrågan.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- Postman för att skicka testförfrågningar till webhooken
- Header Auth-inloggningsuppgifter (i n8n) för att säkra det interna uppslagsanropet
- Lista med API-nycklar (lagra den i noden “Stored Key Registry”)
Svårighetsgrad: Nybörjare. Du klistrar in några värden, kopplar inloggningsuppgifter och kör testförfrågningar.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
En skyddad webhook tar emot en POST-förfrågan. Noden “Protected Webhook Entry” är din publika endpoint. Anropare måste inkludera en x-api-key-header, eftersom det är det enda som bevisar att de får trigga ditt arbetsflöde.
Arbetsflödet ber en intern tjänst verifiera nyckeln. n8n skickar ett HTTP-anrop till en andra webhook (“Key Lookup Webhook”) som beter sig som ett litet privat API. Den här uppdelningen är viktig eftersom den håller din “register”-logik borta från den publika endpointen.
Registret genomsöks efter en match. Den lagrade listan med godkända nycklar expanderas till enskilda poster, filtreras för att hitta den som matchar den inkommande nyckeln och skickas sedan in i en If-kontroll som avgör “auktoriserad” kontra “obehörig”.
Ett tydligt svar returneras direkt. Giltiga förfrågningar får 200 OK med användar-ID så att arbetsflöden längre ned kan lita på identiteten. Ogiltiga förfrågningar får 401 Unauthorized och exekveringen stoppar, vilket är hela poängen.
Du kan enkelt modifiera “Stored Key Registry” för att använda en riktig databasuppslagning utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera webhook-triggern
Konfigurera den skyddade ingångspunkten som tar emot inkommande webhook-förfrågningar och skickar dem vidare in i valideringsflödet.
- Lägg till och öppna Protected Webhook Entry.
- Ställ in Path på
tutorial/secure-webhook. - Ställ in HTTP Method på
POST. - Ställ in Response Mode på
responseNode. - Ställ in Authentication på
headerAuth. - Credential Required: Anslut era
httpHeaderAuth-inloggningsuppgifter i Protected Webhook Entry.
Steg 2: anslut webhooken för uppslag i nyckelregistret
Konfigurera den interna uppslags-endpointen som valideringsförfrågan anropar för att hämta registrerade nycklar.
- Lägg till och öppna Key Lookup Webhook.
- Ställ in Path på
tutorial/secure-webhook/api-keys. - Ställ in Response Mode på
lastNode. - Ställ in Authentication på
headerAuth. - Credential Required: Anslut era
httpHeaderAuth-inloggningsuppgifter i Key Lookup Webhook.
Steg 3: konfigurera det lagrade nyckelregistret och expandering
Definiera de registrerade API-nycklarna och expandera listan till individuella poster för filtrering.
- Öppna Stored Key Registry och lägg till en tilldelning med namnet registered_api_keys med typen
array. - Ställ in värdet till JSON-arrayen som används av arbetsflödet, till exempel:
[{"user_id":"user_1","api_key":"test"},{"user_id":"user_2","api_key":"[CONFIGURE_YOUR_API_KEY]"}]. - Öppna Expand User List och ställ in Field To Split Out på
registered_api_keys.
[CONFIGURE_YOUR_API_KEY] med en riktig nyckel, annars kommer valideringen alltid att misslyckas för den användaren.Steg 4: konfigurera nyckelverifiering och matchningslogik
Routa inkommande webhook-anrop till uppslags-endpointen, filtrera nyckelposterna och utvärdera en träff.
- Öppna Verify Key Request och ställ in URL på
={{ $env.WEBHOOK_URL + ($env.N8N_ENDPOINT_WEBHOOK ?? "webhook") }}/tutorial/secure-webhook/api-keys. - Ställ in Send Body på
trueoch lägg till en body-parameter: api_key =={{ $json.headers['x-api-key'] }}. - Ställ in Authentication på
genericCredentialTypeoch Generic Auth Type påhttpHeaderAuth. - Credential Required: Anslut era
httpHeaderAuth-inloggningsuppgifter i Verify Key Request. - Öppna Locate Key Record och ställ in filtervillkoret så att Left Value
={{ $json.api_key }}jämförs med Right Value={{ $('Key Lookup Webhook').last().json.body.api_key }}. - Öppna Key Match Check och ställ in villkoret med Left Value
={{ $json.user_id }}och Right Value={{ $('Protected Webhook Entry').item.json.headers['x-api-key'] }}.
Steg 5: konfigurera svar för lyckat resultat och obehörig
Returnera ett strukturerat svar baserat på om en giltig nyckel hittades.
- Öppna Return Success Response och ställ in Respond With på
json. - Ställ in Response Body på
={ "status": "success", "user_id": "{{ $json.user_id }}" }. - Öppna Return Unauthorized Reply och ställ in Respond With på
json. - Ställ in Response Code på
401och Response Body på{ "error": "Please provide a valid x-api-key header." }.
Steg 6: konfigurera testförfrågan för verktyg (valfritt)
Använd den inbyggda testförfrågan för att testa den skyddade webhooken från början till slut.
- Öppna Utility: Probe Protected Webhook och ställ in URL på
={{ $env.WEBHOOK_URL + ($env.N8N_ENDPOINT_WEBHOOK ?? "webhook") }}/tutorial/secure-webhook. - Ställ in Method på
POSToch aktivera Send Headers. - Lägg till en header-parameter x-api-key med värdet
test. - Credential Required: Anslut era
httpHeaderAuth-inloggningsuppgifter i Utility: Probe Protected Webhook.
Steg 7: testa och aktivera ert arbetsflöde
Verifiera att webhooken returnerar success för giltiga nycklar och obehörig för ogiltiga nycklar, och aktivera sedan arbetsflödet.
- Klicka på Execute Workflow och trigga Utility: Probe Protected Webhook för att skicka en testförfrågan.
- Bekräfta att Return Success Response returnerar en JSON-payload med
"status": "success"och korrektuser_id. - Skicka en förfrågan med en ogiltig
x-api-keyoch verifiera att Return Unauthorized Reply svarar med ett401-fel och meddelande. - När allt fungerar, växla arbetsflödet till Active för att ta emot produktionsförfrågningar.
Tips för felsökning
- n8n-uppgifter för Header Auth kan löpa ut eller kopplas till fel noder. Om den interna uppslagningen börjar returnera fel, kontrollera först val av inloggningsuppgifter på webhook- och HTTP Request-noderna.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om noder längre ned fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att sitta och redigera utdata för alltid.
Snabba svar
Cirka 2 minuter när du har dina nycklar redo.
Nej. Du klistrar in nyckel-/värdepar i registret och kopplar inloggningsuppgifter i n8n.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna in Postman (gratis för grundläggande testning) och den databas du senare använder för nyckellagring.
Två alternativ: n8n Cloud (hanterat, enklast uppsättning) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärt och kör n8n bra. Self-hosting ger dig obegränsade exekveringar men kräver grundläggande serverhantering.
Ja, och det bör du sannolikt om detta ska in i produktion. Byt ut mönstret “Stored Key Registry” (Set) + “Key Lookup Webhook” mot en riktig datalagring som Supabase eller Postgres, och behåll sedan samma “Key Match Check” samt 200/401-svar. Vanliga justeringar är rate limits per nyckel, utgående nycklar och att returnera en mer detaljerad success-payload (t.ex. kontonivå eller tillåtna actions).
Oftast saknas headern eller så är den felaktigt namngiven. I Postman: säkerställ att du skickar x-api-key (exakt stavning) och att förfrågan är en POST till rätt webhook-test-URL från n8n. Om du anropar produktions-URL:en, bekräfta att arbetsflödet är aktivt och inte bara i “test”-läge.
I self-hosted n8n finns ingen exekveringstak, och just det här arbetsflödet är lättviktigt, så de flesta små team kan hantera många dagliga förfrågningar på en modest VPS. I n8n Cloud beror dina månatliga exekveringar på planens gränser; gatekeeper-kontrollen är en exekvering per inkommande anrop, plus det interna uppslagsarbetet i samma körning.
Ofta, ja, eftersom du kan returnera ett korrekt 200/401-svar och styra logiken strikt. n8n är också smidigare när du vill ha en intern webhook som “uppslagstjänst” och en separat publik entrypoint, eftersom grening och filtrering inte blir dyra när komplexiteten växer. Zapier och Make kan fortfarande fungera för enkla fall, men du kan hamna i krångliga workarounds för autentisering och svar. Om du skyddar kundnära endpoints är det värt att göra detta ordentligt. Prata med en automationsexpert om du vill ha en snabb rekommendation.
När detta väl är på plats slutar slumpmässigt webhook-brus att bli till riktigt arbete. Du får korrekta 200-svar för giltiga anrop, korrekta 401-svar för allt annat och ett arbetsflöde du kan lita på.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.