Ein n8n Workflow ist eine Kette von Nodes: Ein Trigger startet den Ablauf, die folgenden Nodes holen, prüfen und formen Daten, am Ende steht ein Ergebnis. Du erstellst ihn im Editor, indem du einen Trigger setzt, Nodes anhängst und verbindest und mit „Execute workflow“ testest. Damit er von selbst läuft, musst du ihn veröffentlichen: Seit n8n 2.0 heißt das „Publish“ und ersetzt den alten Aktiv-Schalter. Jeder Workflow ist eine JSON-Datei, die du exportieren, in eine andere Instanz importieren oder per API anlegen kannst.
Ich habe n8n lange in meinem eigenen Kubernetes-Cluster betrieben und darin Prozesse gebaut. Die beiden Beispiele unten stammen aus einem Test vom 31.10.2026 mit n8n 2.45.7 in Docker auf einem Mac. Beide Beispiele brauchen keine Zugangsdaten zu externen Diensten. Für die lokale n8n-Instanz legst du bei der Einrichtung ein Owner-Konto an. Die Testumgebung enthielt keine Kundendaten. Was ein Workflow allgemein ist, steht in Was ist ein Workflow? Einfach erklärt. Wie du n8n selbst aufsetzt, steht in n8n installieren: Docker oder Kubernetes.
Was ein n8n Workflow ist: Trigger, Nodes, Daten
Laut Doku ist ein Workflow „a collection of nodes connected together to automate a process“. Drei Begriffe reichen für den Anfang:
- Trigger: der erste Node. Er legt fest, wann der Workflow läuft, etwa per Zeitplan, per Webhook oder von Hand. Laut Doku braucht jeder produktive Workflow mindestens einen.
- Nodes: die Schritte dazwischen. Jeder Node bekommt Daten als JSON, arbeitet damit und gibt JSON weiter.
- Ausdrücke: Werte in doppelten geschweiften Klammern, zum Beispiel
{{ $json.body.email }}. Damit greifst du auf die Daten des vorherigen Nodes zu.
Für Testzwecke reicht n8n lokal auf dem eigenen Rechner. Im Test lief es im Kern mit diesem Befehl (dazu kamen Zeitzone und eigene Namen): docker run -d --name n8n -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n:2.45.7. Die Freigabe nur auf 127.0.0.1 sorgt dafür, dass niemand aus dem Netzwerk an die Instanz kommt. Beim ersten Aufruf von http://localhost:5678 legst du ein Owner-Konto an, das nur in dieser Instanz existiert.
n8n Workflow erstellen: Beispiel Kontaktanfrage per Webhook
Das erste Beispiel nimmt eine Anfrage aus einem Formular an, prüft die Pflichtfelder und antwortet mit einer Bestätigung oder einer Ablehnung. Es besteht aus fünf Nodes:
Im Edit-Fields-Node standen diese vier Felder:
name {{ $json.body.name.trim() }}
email {{ $json.body.email.trim().toLowerCase() }}
anliegen {{ $json.body.nachricht }}
eingang {{ $now.toISO() }}
Die Doku empfiehlt genau diese Aufteilung: Daten zuerst in Edit Fields vorbereiten, statt komplizierte Ausdrücke über viele Nodes zu verteilen. Später hängst du statt der Antwort einen Node an, der die Anfrage in dein CRM oder eine Tabelle schreibt. Erst dann brauchst du Zugangsdaten.
Testen und veröffentlichen: Test-URL und Produktions-URL
Jeder Webhook-Node hat zwei Adressen. Die Test-URL (/webhook-test/anfrage) nimmt einen Aufruf an, nachdem du im Editor „Listen for test event“ gewählt hast, und bleibt laut Doku 120 Sekunden offen. Die Daten siehst du dann direkt auf der Leinwand. Die Produktions-URL (/webhook/anfrage) registriert n8n erst, wenn du den Workflow veröffentlichst.
Vor dem Veröffentlichen antwortete die Produktions-URL im Test so:
HTTP 404
{"code":404,"message":"The requested webhook \"POST anfrage\" is not registered.",
"hint":"The workflow must be active for a production URL to run successfully. ..."}
Der Hinweis spricht noch vom Aktiv-Schalter, gemeint ist der Publish-Knopf oben rechts. Nach dem Veröffentlichen lieferten vier Aufrufe diese Antworten:
$ curl -X POST http://127.0.0.1:5678/webhook/anfrage -H 'Content-Type: application/json' \
-d '{"name":" Erika Muster ","email":" Erika@Example.com","nachricht":"Bitte um Rückruf wegen Angebot"}'
{"status":"angenommen","name":"Erika Muster","eingang":"2026-10-31T11:23:46.830+01:00"} HTTP 200
-d '{"name":"Max","email":"max-at-example.com"}' -> {"status":"abgelehnt",...} HTTP 400
-d '{"name":"Max"}' -> {"status":"abgelehnt",...} HTTP 400
GET statt POST -> "This webhook is not registered for GET requests." HTTP 404
Leerzeichen und Großbuchstaben hat der Edit-Fields-Node entfernt. Produktive Aufrufe erscheinen nicht auf der Leinwand, sondern im Reiter „Executions“ des Workflows.
Fehlerfälle aus dem Test
Drei Dinge liefen anders, als man erwarten würde.
Fehlende Felder sind kein Fehler. In der ersten Fassung prüfte der If-Node nur die E-Mail. Eine Anfrage ohne Namen lief durch, $json.body.name.trim() ergab null, die Antwort war „angenommen“ mit "name":null, die Ausführung stand auf „Success“. Erst die zweite Bedingung „name ist nicht leer“ hat das abgefangen. Prüf deshalb jedes Pflichtfeld ausdrücklich im If-Node.
Abgelehnt heißt nicht fehlgeschlagen. Die Antworten mit HTTP 400 stehen in der Ausführungsliste als „Success“, denn der Workflow hat getan, was er sollte. Wer Ablehnungen zählen will, muss sie selbst festhalten.
Ein echter Fehler stoppt den Workflow. Dazu unten mehr am zweiten Beispiel.
Zweites n8n Workflow Beispiel: Daten aus einer API holen
Das zweite Beispiel startet von Hand, ruft per HTTP Request die Wetter-API von Open-Meteo ab (ohne Schlüssel, laut Nutzungsbedingungen nur für nicht-kommerzielle Zwecke frei), wählt drei Felder aus und verzweigt mit einem If-Node: unter 10 Grad „Jacke mitnehmen“, sonst „Keine Jacke nötig“.
Verbinde die Nodes so: Manueller Start → Wetter abrufen → Felder auswählen → Unter 10 Grad? Der true-Ausgang führt zu ‚Hinweis: kalt‘, der false-Ausgang zu ‚Hinweis: mild‘. Die Einstellungen aus dem Test:
Für den Fehlerzweig setzt du im HTTP-Request-Node ‚On Error‘ auf ‚Continue (using error output)‘. Verbinde dessen Fehlerausgang mit einem weiteren Edit-Fields-Node. Dort setzt du fehler auf {{ $json.error.message }} und zeitpunkt auf {{ $now.toISO() }}. Um diesen Zweig nachzustellen, ersetze latitude=52.52 vorübergehend durch latitude=abc. Danach wieder auf 52.52 zurückstellen.
Der letzte Node lieferte im Test:
{ "zeit": "2026-10-31T11:15", "temperatur": 10.9, "wind_kmh": 9.5,
"hinweis": "Keine Jacke nötig: 10.9 °C" }
Dann der Fehlerfall: Breitengrad abc statt 52.52. Der HTTP-Request-Node brach ab, die Ausführung stand auf „Error“:
Bad request - please check your parameters
400 - "{\"reason\":\"Invalid value: Cannot initialize Float from invalid String value abc\",\"error\":true}"
Für solche Fälle gibt es in den Einstellungen jedes Nodes „On Error“. Mit „Continue (using error output)“ bekommt der Node einen zweiten Ausgang. Im Test hing dort ein Edit-Fields-Node „Fehler festhalten“, der die Fehlermeldung und den Zeitpunkt speicherte; die Ausführung lief dann bis zum Ende durch. Für Benachrichtigungen bei jedem Fehlschlag legst du laut Doku einen eigenen Fehler-Workflow mit dem Error Trigger an und trägst ihn in den Workflow-Einstellungen unter „Error workflow“ ein.
n8n Workflow importieren und exportieren
Workflows sind JSON. Im Editor findest du im Workflow-Menü (drei Punkte) „Download“, „Import from File“ und „Import from URL“. Für mehrere Instanzen oder Backups gibt es die Kommandozeile im Container:
docker exec -u node n8n n8n export:workflow --id=<ID> --pretty --output=/tmp/anfrage.json
docker exec -u node n8n n8n import:workflow --input=/tmp/anfrage.json
docker exec -u node n8n n8n list:workflow
Drei Beobachtungen aus dem Test:
- Die Exportdatei enthält mehr als den Workflow. Im Feld
shared stand der Projektname mit Name und E-Mail-Adresse des Kontos. Die Doku warnt zusätzlich, dass Namen von Zugangsdaten und aus cURL übernommene Header im JSON landen können. Lies die Datei, bevor du sie weitergibst.
- Gleiche ID überschreibt. Der erneute Import derselben Datei legte keinen zweiten Workflow an, es blieben zwei Einträge. Erst ohne Feld
id entstand eine Kopie. Die Doku sagt dazu: Workflows mit gleicher ID werden überschrieben.
n8n execute neben dem laufenden Server brach zuerst ab: „n8n Task Broker's port 5679 is already in use.“ Mit -e N8N_RUNNERS_BROKER_PORT=5681 lief der Befehl.
Über die öffentliche API geht dasselbe per Schlüssel (in n8n unter Settings, n8n API, mit eingeschränkten Rechten): POST /api/v1/workflows legt an, POST /api/v1/workflows/<id>/activate veröffentlicht. Achtung: Ein PUT auf einen veröffentlichten Workflow schaltete im Test die neue Fassung sofort live. Im Editor bleiben Änderungen dagegen Entwurf, bis du auf Publish klickst. Die API selbst erklärt Was ist eine API? Schnittstelle erklärt.
n8n Vorlagen: Templates sinnvoll nutzen
Die Vorlagen-Bibliothek auf n8n.io/workflows nannte am 31.10.2026 im Seitentitel 13.825 Workflows aus der Community. Eine Vorlage ist laut Doku ein fertiger Workflow, bei dem du meist Zugangsdaten eintragen und Einstellungen anpassen musst. Importier sie zuerst in eine Testinstanz, lies jeden Node und prüf vor allem HTTP-Request- und Code-Nodes: Wohin gehen die Daten?
Häufige Fragen
Was ist ein n8n Workflow?
Eine Folge verbundener Nodes, die ein Trigger startet. n8n speichert sie als JSON. Jeder Durchlauf ist eine Ausführung; in den bezahlten Plänen zählen laut Doku die automatischen Durchläufe aufs Kontingent.
Warum antwortet mein Webhook mit 404?
Meist ist der Workflow nicht veröffentlicht oder die Methode stimmt nicht. Die Produktions-URL gibt es erst nach Publish, die Test-URL nur 120 Sekunden nach „Listen for test event“. Ein GET auf einen POST-Webhook ergab im Test ebenfalls 404.
Wie importiere ich einen n8n Workflow?
Im Editor über das Workflow-Menü mit „Import from File“ oder „Import from URL“, auf dem Server mit n8n import:workflow --input=<datei>. Vorher die Datei auf Namen, Adressen und Zugangsdaten prüfen.
Gibt es ein n8n Tutorial auf Deutsch?
Die offizielle Doku von n8n ist englisch. Dieses Tutorial ist deutsch, und die Nodes der beiden Beispiele tragen deutsche Namen. Bau sie nach und ändere dann einen Schritt nach dem anderen, so lernst du die Oberfläche an einer echten Aufgabe.
Brauche ich für einen n8n Workflow Zugangsdaten?
Nicht für die Logik. Webhook, If, Edit Fields und HTTP Request auf eine offene API laufen ohne. Zugangsdaten brauchst du erst für Dienste mit Anmeldung, etwa Postfach, CRM oder ein Sprachmodell.
Wie du weitermachst
Läuft dein erster Workflow, liegt der nächste Schritt nahe: ein KI-Baustein darin. Wie ein Agent in n8n aufgebaut ist und was ich aus meinem Betrieb mitgenommen habe, steht in n8n KI-Agent erstellen: was ich gelernt habe. Ob ein Workflow-Baukasten überhaupt das richtige Werkzeug ist, vergleicht n8n, Make oder Claude: was wofür?. Was Ausführungen in der Cloud kosten, steht in n8n Kosten: Cloud, Self-Hosted, Business. Alles rund um Agenten sammle ich auf der Seite KI-Agenten.
Wenn dein Workflow hängt: Bring die Fehlermeldung oder die Exportdatei (ohne Zugangsdaten) in die Calls von Claude Practitioners, dort schauen wir sie gemeinsam an.
