n8n Praxis: Webhook-Trigger und IF/Switch-Bedingungsverzweigungen

Der orangefarbene Button „Test Workflow“ wurde zum siebzehnten Mal geklickt.

Jedes Mal mussten Sie manuell auslösen. Geht das nicht wie bei einer echten API – jemand ruft an, und der Workflow startet von selbst? Später stellte sich heraus: n8n hat etwas namens Webhook – im Grunde eine Türklingel. Wird gedrückt, startet der Workflow.

In diesem Artikel geht es darum, wie Sie diese Klingel installieren und Besucher je nach Anliegen in unterschiedliche Räume leiten. Wenn Sie n8n-Basisknoten schon kennen, Ihre Workflows sich aber noch „passiv wartend“ anfühlen, sollte das hier neue Impulse geben.

Inhalt:

• Webhook-Knoten: die verwirrenden Parameter verständlich konfigurieren
• IF und Switch: wann welcher Knoten passt
• Ein vollständiges Bestellungs-Beispiel zum direkten Übernehmen
• Fallstricke in der Produktion

1. Webhook-Knoten im Detail

Kurz vorweg: Webhook und zeitgesteuerter Trigger sind grundverschieden.

Ein zeitgesteuerter Trigger ist ein Wecker – er klingelt in festen Abständen, egal ob draußen etwas passiert. Ein Webhook ist eine Türklingel – er klingelt nur, wenn jemand drückt. Das ist Ereignissteuerung. Vorteil: Sie müssen nicht alle fünf Minuten zur Tür schauen, ob ein Paket da ist; der Zusteller klingelt, und Sie wissen Bescheid. Laut offiziellen Angaben reduzieren Webhooks den 90-95% Polling-Aufwand – weniger Ressourcen, weniger Wartezeit.

1.1 Welche HTTP-Methode wählen?

Im Webhook-Knoten füllen Sie zuerst die HTTP Method aus. n8n unterstützt DELETE, GET, HEAD, PATCH, POST und PUT.

Die Wahl hängt vom Ziel ab:

• POST: Daten empfangen, z. B. Formular oder neue Bestellung. Am häufigsten.
• GET: Einfacher Trigger, z. B. Kurzlink – Klick startet den Workflow.
• PUT/PATCH: Updates, z. B. Bestellstatus ändern.

Meist nutze ich POST, weil der Body Daten mitbringt.

1.2 Vier Antwortmodi

Der Parameter „Response Mode“ legt fest, wie n8n dem Aufrufer antwortet:

Achtung: Bei „Immediately“ erhält der Aufrufer 200 und geht – Fehler in späteren Knoten bleiben unsichtbar. Für Hintergrundjobs Fehlerbenachrichtigungen mitplanen.

1.3 RESTful-Routing mit Path-Parametern

Im Path lassen sich dynamische Routen setzen, z. B. orders/:orderId. Nach dem Doppelpunkt steht der Variablenname; der Wert wird aus der URL gelesen.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Aufruf /orders/12345 → im Workflow {{ $params.orderId }} liefert 12345. Sauberer als alles in der Query-String.

1.4 Payload-Größenlimit

Maximale Webhook-Payload: 16MB Maximale Payload. Darüber gibt es Fehler.

Bei großen Dateien zwei Wege:

1. Umgebungsvariable N8N_PAYLOAD_SIZE_MAX anpassen
2. Datei in Object Storage legen und nur die URL an den Webhook senden

16 MB reichen meist. Für große Dateien ist Variante 2 robuster.

2. IF vs. Switch: Bedingungsverzweigungen wählen

Beide Knoten leiten Daten weiter – falsch gewählt wird es unübersichtlich: verschachtelte IFs wie Spaghetti oder ein Switch, obwohl zwei Ausgänge reichen.

2.1 IF-Knoten: Entweder oder

Der IF-Knoten hat zwei Ausgänge: true und false.

Wie an der Tür: „Ist das Frischware?“ Ja → Kühlschrank, nein → vor die Tür. Einfach.

IF unterstützt viele Typen: String, Number, Date & Time, Boolean, Array, Object. Beispiele:

• String: contains, starts with, ends with, matches regex
• Number: is greater than, is less than
• Boolean: is true, is false
• Array: contains, length greater than

2.2 Switch-Knoten: Mehrere Wege

Der Switch-Knoten kann viele Ausgänge haben – „Welche Abteilung?“ Finanzen hier, Technik dort, Operations woanders.

Zwei Modi:

• Rules: Bedingung pro Ausgang wie ein Formular. Übersichtlich für Einsteiger.
• Expression: JavaScript-Ausdruck liefert die Ausgangsnummer. Flexibel für komplexe Logik.

2.3 Entscheidungshilfe

Merksatz: IF hinter IF hinter IF – dann ist Switch fällig.

2.4 Unterstützte Datentypen

IF und Switch vergleichen u. a.:

• String: exists, is empty, contains, matches regex …
• Number: größer, kleiner, gleich …
• Date & Time: zeitliche Reihenfolge
• Boolean: wahr/falsch
• Array: Länge, Element enthalten
• Object: vorhanden, leer, nicht leer

Date & Time ist praktisch – z. B. ob eine Bestellung überfällig ist, per Datumsvergleich.

3. Praxis: automatische Bestellstatus-Verarbeitung

Ein Bekannter betrieb einen kleinen Online-Shop – Bestellungen manuell im Backend, Benachrichtigungen, Anrufe. Ich sagte: n8n kann das. Er war skeptisch.

Zwei Wochen später fragte das Lager: „Warum geht plötzlich keine Bestellung mehr verloren?“

3.1 Anforderungen

• Neue Bestellung (pending) → Lager informieren
• Bezahlt (paid) → Bestätigungsmail
• Versendet (shipped) → Tracking aktualisieren
• Storniert (cancelled) → Rückerstattung

Vier Status – ideal für Switch.

3.2 Webhook-Konfiguration

Webhook-Knoten:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

• HTTP Method: POST
• Path: orders/:orderId
• Response Mode: When Last Node Finishes (Ergebnis zurückgeben)
• Authentication: Header Auth

Sicherheit: Header Auth mit X-Shop-Secret und zufälligem Wert – nur Systeme mit diesem Secret dürfen aufrufen.

3.3 Switch-Regeln

Switch im Modus Rules, vier Regeln für vier Status:

Regel 1: {{ $json.status }} equals "pending" → Ausgang: pending
Regel 2: {{ $json.status }} equals "paid" → Ausgang: paid
Regel 3: {{ $json.status }} equals "shipped" → Ausgang: shipped
Regel 4: {{ $json.status }} equals "cancelled" → Ausgang: cancelled

Fallback Output: Extra Output – unbekannte Status wie „unknown“ blockieren den Flow nicht.

3.4 Vollständiger Workflow als JSON

Direkt in n8n importierbar:

{
  "name": "Order Processing",
  "nodes": [
    {
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "position": [250, 300],
      "parameters": {
        "httpMethod": "POST",
        "path": "orders/:orderId",
        "responseMode": "responseNode",
        "authentication": "headerAuth"
      }
    },
    {
      "name": "Switch",
      "type": "n8n-nodes-base.switch",
      "position": [500, 300],
      "parameters": {
        "mode": "rules",
        "rules": [
          { "output": "pending", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "pending" } },
          { "output": "paid", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "paid" } },
          { "output": "shipped", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "shipped" } },
          { "output": "cancelled", "conditions": { "value1": "{{ $json.status }}", "operation": "equals", "value2": "cancelled" } }
        ],
        "fallbackOutput": "extra"
      }
    },
    {
      "name": "Notify Warehouse",
      "type": "n8n-nodes-base.slack",
      "position": [750, 200]
    },
    {
      "name": "Send Confirmation",
      "type": "n8n-nodes-base.emailSend",
      "position": [750, 300]
    },
    {
      "name": "Update Tracking",
      "type": "n8n-nodes-base.httpRequest",
      "position": [750, 400]
    },
    {
      "name": "Process Refund",
      "type": "n8n-nodes-base.stripe",
      "position": [750, 500]
    }
  ],
  "connections": {
    "Webhook": { "main": [[{ "node": "Switch", "type": "main", "index": 0 }]] },
    "Switch": {
      "main": [
        [{ "node": "Notify Warehouse", "type": "main", "index": 0 }],
        [{ "node": "Send Confirmation", "type": "main", "index": 0 }],
        [{ "node": "Update Tracking", "type": "main", "index": 0 }],
        [{ "node": "Process Refund", "type": "main", "index": 0 }]
      ]
    }
  }
}

JSON kopieren und in n8n einfügen. Slack-, Email-, HTTP-Request- und Stripe-Knoten mit eigenen Zugangsdaten ersetzen.

3.5 Test und Go-Live

n8n bietet zwei URLs:

• Test URL: Entwicklung – läuft nur bei manuellem Test
• Production URL: Nach Aktivierung für echte Aufrufe

Ablauf:

1. Test URL mit curl oder Client aufrufen, Reihenfolge und Daten prüfen
2. Wenn alles passt: Schalter „Active“ oben rechts
3. Production URL an Shop-System oder Middleware (z. B. Zapier) übergeben

Test per curl:

curl -X POST https://your-n8n-instance.com/webhook/orders/12345 \
  -H "Content-Type: application/json" \
  -H "X-Shop-Secret: your-secret-key" \
  -d '{"status": "paid", "customer_email": "[email protected]"}'

200 und Eintrag in den Executions → es funktioniert.

4. Produktion: typische Fallstricke

Ein durchlaufender Workflow ist noch kein produktionsreifer Dienst. Ein paar Lektionen aus der Praxis.

4.1 Authentifizierung nicht vernachlässigen

Header Auth ist der erste Schritt. Bei festen Aufrufer-IPs zusätzlich IP Whitelist.

Unter Advanced Options des Webhook-Knotens „IP Whitelist“ mit erlaubten IPs – andere werden abgewiesen, der Workflow startet nicht.

JWT Auth ist möglich, etwas aufwendiger. Für eigene Systeme reichen oft Header Auth + IP Whitelist.

4.2 Fehler müssen jemanden erreichen

Bei Webhook-Fehlern sieht der Aufrufer vielleicht nur 500 – Sie brauchen Details.

Error-Trigger-Knoten im Workflow, bei Fehler Slack (oder anderes) mit Meldung und Execution-ID:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Error Trigger → Slack (Fehlertext und Execution-ID)

So sehen Sie nachts auf dem Handy, was schiefging – nicht erst nach Nutzerbeschwerden am Morgen.

4.3 Performance: sofort antworten

Viele externe APIs hinter dem Webhook (Lager, Mail, Payment) → lange Laufzeit, Timeout beim Aufrufer.

Dann Response Mode „Immediately“: zuerst 200, Verarbeitung im Hintergrund. Nachteil: kein finales Ergebnis im HTTP-Response – Status separat abfragen.

Passt für: Batch-Jobs, unkritische Benachrichtigungen. Weniger für: Zahlungsbestätigung, Live-Abfragen.

4.4 Executions zum Debuggen

Links „Executions“: Eingaben, Ausgaben, Dauer pro Knoten, Fehler.

Standard: die letzten 1000 Läufe. Bei hohem Volumen EXECUTIONS_DATA_MAX_AGE anpassen oder Logs exportieren.

Test- und Production-Executions getrennt ansehen – nicht verwechseln.

Fazit

Webhook ist die Türklingel für n8n – externer Aufruf, Workflow läuft. HTTP Method und Response Mode bewusst wählen; Path-Parameter statt langer Query-Strings.

IF bei zwei Ausgängen, Switch ab drei. Keine IF-Matroschkas.

Den Bestell-Workflow können Sie übernehmen – Slack, Email und Stripe anpassen, mit Test URL prüfen, dann aktivieren.

Sicherheit: Header Auth, wo möglich IP Whitelist. Fehlerbenachrichtigung einplanen – sonst merken Sie Probleme zu spät.

Fragen gerne in den Kommentaren – oder in der n8n-Community nachschlagen; dort gibt es viel Erfahrung.