Webhook (n8n)

Typische Use-Cases

1. Formulare: Jemand füllt Typeform/GravityForms aus -> Daten gehen an n8n -> n8n speichert sie in Excel.
2. Shop-Systeme: Jemand kauft auf Shopify -> Shopify ruft den Webhook -> n8n erstellt Rechnung.
3. Verbindung von Tools: Ein Skript auf deinem Server meldet "Backup fertig" an n8n -> n8n postet in Slack.

Production vs. Test URL

Der Webhook-Node hat zwei URLs. Das verwirrt viele Anfänger:

1. Test URL: Funktioniert nur, wenn du im Editor gerade den "Listen for Event"-Knopf gedrückt hast. Nur für einen Testlauf. Gut zum Entwickeln.
2. Production URL: Die "echte" Adresse. Funktioniert immer (wenn der Workflow auf "Active" steht). Diese trägst du bei Stripe/Shopify ein.

1. HTTP Methods (GET vs. POST)

Du musst einstellen, worauf der Webhook hört:

• GET: Wenn du die URL einfach im Browser aufrufst. Keine Daten (außer Query Params ?id=123).
• POST: Der Standard für Datenübertragung. Hier sendet die fremde App ein JSON-Paket im Body ({"kunde": "Max"}).

2. Response Mode (Antworten)

Was sieht der Aufrufer, nachdem er geklingelt hat?

• Immediate (Sofort): n8n sagt nur "Habe verstanden (200 OK)" und legt auf. Der Workflow läuft im Hintergrund weiter. (Standard für Webhooks).
• Last Node: n8n wartet, bis der ganze Workflow fertig ist, und schickt das Ergebnis des letzten Nodes zurück. Damit kannst du dir deine eigene API bauen! (z. B. eine URL, die dir das aktuelle Wetter aus 3 Quellen berechnet zurückgibt).

3. Security (Authentication)

Jeder, der die URL kennt, kann deinen Workflow starten! Für sensible Prozesse musst du den Webhook schützen:

• Basic Auth: Benutzername & Passwort.
• Header Auth: Der Aufrufer muss einen geheimen Token (X-API-KEY: geheim) mitsenden.

HMAC Payload Validation (Die Signatur prüfen)

Dass eine URL geheim ist, schützt nicht vor Hackern (Security by Obscurity ist ein Mythos). Richtig implementierte Banken/Shops (wie Stripe oder Shopify) signieren ihre Webhooks cryptografisch per HMAC (Hash-based Message Authentication Code). Stripe berechnet einen SHA-256 Hash aus dem (Body-Payload + Deinem Stripe-Secret) und sendet ihn im HTTP-Header Stripe-Signature mit. In n8n konfigurierst du im Webhook Node den "Crypto" Block (oder durch nachfolgenden Crypto Node). n8n nimmt denselben Payload, nimmt dasselbe Secret und hashte es intern nochmals. Wenn der berechnete Hash auch nur 1 Bit vom gesendeten Header abweicht, droppt n8n den Ping aggressiv mit 401 Unauthorized – selbst wenn die URL völlig öffentlich ist. So wird MITM-Spoofing vereitelt.

CORS (Cross-Origin Resource Sharing)

Willst du den n8n Webhook direkt aus via JavaScript-Ajax (Axios/Fetch) in den Browser einer fremden Webseite feuern (Frontend Submits), zerschellst du an den CORS-Richtlinien. Der Browser blockt Anfragen von meinshop.com an Server firma.de/webhook, bis der Server Header-Erlaubnisse sendet. Der Webhook-Node muss für diesen Modus auf "Response Headers" justiert werden: Access-Control-Allow-Origin: * (oder spezifische Domains). Wenn der Browser vorab einen "OPTIONS"-Preflight Call macht, muss n8n diesen korrekt mit 200 OK beantworten, da JavaScript ansonsten die POST-Nutzdaten unterdrückt.

Synchronous Respond-to-Trigger Loops

Der Modus "Respond using Last Node" ist architektonisch extrem komplex, weil der HTTP Aufruf des Clients "hängt", während die Nodes rattern. Das bedeutet aber auch: Der aufrufende Server (z.B. Salesforce) hat ein striktes Limit (oft 10 oder 30 Sekunden). Läuft in DIESEM Workflow nun ein fetter Loop, der KI-Bilder mit Stable Diffusion rendert, wartet der n8n-Workflow 60 Sekunden, bis er das Bild "Synchron" als URL zum Webhook retournieren kann. Für Salesforce rennt die Leitung nach 30 Sekunden in den "Read Timeout". Der Workflow beendet zwar die Bild-KI, aber der Empfänger hat längst zornig kapituliert (Failed State). Sowas löst man in Webhooks durch Asynchrone Callbacks: Immediate Response "200 OK - Job Started", und am Ende des n8n Workflows sendet dieser per separatem "HTTP Request Node" aktiv einen POST zurück an Salesforces Callback-API.