n8n Webhook und API-Integration: HTTP-Node-Leitfaden
n8n Webhook API Der Webhook Trigger Node von n8n wandelt eingehende HTTP-Anfragen in Workflow-Ausführungen um, während der HTTP Request Node aus dem Workflow heraus jede REST-API aufruft. Gemeinsam bieten diese beiden Nodes den flexibelsten Weg, Dienste ohne nativen n8n-Connector zu integrieren.
Webhook und HTTP Node in n8n: Der Unterschied zwischen Trigger und Request
Der Webhook Trigger Node ist eine URL, die n8n nach außen öffnet; eingehende HTTP-Anfragen an diese URL starten einen Workflow. Der HTTP Request Node sendet Anfragen aus dem Workflow heraus an externe Dienste. Der eine empfängt eingehenden Traffic, der andere erzeugt ausgehende Anfragen.
Das Verständnis des Unterschieds zwischen n8ns zwei HTTP-fokussierten Nodes ist die Grundlage für eine korrekte Integrationsarchitektur. n8ns Workflow-Engine empfängt Ereignisse über Trigger-Nodes und verarbeitet sie durch aufeinanderfolgende Nodes. Der Webhook Trigger ist der flexibelste dieser Trigger: n8n stellt eine eindeutige URL bereit, und jede HTTP-Anfrage an diese URL — GET, POST, PUT, PATCH oder DELETE — führt den Workflow sofort aus.
Der HTTP Request Node erfüllt eine andere Rolle. Während der Workflow läuft, sendet er eine Anfrage an eine beliebige externe API und leitet die Antwort an nachfolgende Nodes weiter. Sie können damit eine Verbindung zu Ihrem CRM, ERP oder jeder SaaS-Plattform herstellen. Jeder Dienst, der über HTTP kommuniziert, kann über diesen Node in einen Workflow eingebunden werden, unabhängig davon, ob n8n einen nativen Connector dafür hat.
| Eigenschaft | Webhook Trigger Node | HTTP Request Node |
|---|---|---|
| Rolle | Eingehende Anfragen empfangen (passiver Listener) | Ausgehende Anfragen senden (aktiver Aufrufer) |
| Position | Workflow-Start (Trigger) | Beliebige Stelle im Workflow |
| Richtung | Extern zu n8n | n8n nach extern |
| Typische Nutzung | Webhook-Endpoint veröffentlichen | REST-API aufrufen |
| Authentifizierung | Header Auth, Basic Auth, JWT (optional) | API-Key, OAuth2, Header Auth, Basic Auth |
Webhook Trigger Einrichten: URL, HTTP-Methode und Authentifizierung
Nach dem Hinzufügen des Webhook Trigger Nodes stellt n8n zwei URLs bereit: eine zum Testen und eine für die Produktion. HTTP-Methode, Antwortmodus und optionale Authentifizierung werden direkt im Node-Panel konfiguriert.
Wenn Sie den Webhook Trigger Node hinzufügen, generiert n8n automatisch einen eindeutigen Pfad. Diesen Pfad können Sie anpassen — zum Beispiel einen aussagekräftigen Namen wie `/webhook/kundenregistrierung` vergeben. n8n zeigt die Test-URL (`/webhook-test/...`) und die Produktions-URL (`/webhook/...`) getrennt an. Die Test-URL ist nur aktiv, wenn Sie den Workflow manuell ausführen; die Produktions-URL ist aktiv, solange der Workflow aktiviert ist.
Die HTTP-Methode als POST zu belassen ist für die meisten Szenarien geeignet; GET, PUT, PATCH oder DELETE sind jedoch ebenfalls verfügbar. Der Antwortmodus ist eine wichtige Entscheidung: 'Immediately' gibt sofort 200 OK zurück, sobald die Anfrage empfangen wird, während der Workflow im Hintergrund weiterläuft. 'When Last Node Finishes' wartet auf den Abschluss des gesamten Workflows und gibt die Ausgabe des letzten Nodes als Antwort zurück — dieser Modus wird für synchrone API-Gateway-Szenarien bevorzugt.
- Pfad: Optionaler benutzerdefinierter URL-Pfad (z. B. /webhook/orders)
- HTTP-Methode: GET, POST, PUT, PATCH, DELETE oder ANY
- Antwortmodus: Immediately oder When Last Node Finishes
- Antwortdaten: Last Node oder No Data
- Authentifizierung: None, Basic Auth oder Header Auth
Wenn die Authentifizierung aktiviert ist, lösen nur Anfragen mit den korrekten Anmeldedaten den Workflow aus; nicht authentifizierte Anfragen werden mit 401 abgelehnt. Dies schützt Ihren Webhook-Endpoint vor unbefugten Aufrufen und hilft, Unternehmens-Sicherheitsanforderungen zu erfüllen. Für eine detaillierte Betrachtung der Unternehmens-Sicherheitskonfiguration empfehlen wir den n8n-Sicherheits- und Corporate-Governance-Leitfaden.
Jede API mit dem HTTP Request Node aufrufen
Der HTTP Request Node ermöglicht die Konfiguration von URL, HTTP-Methode, Headern, Query-Parametern, Request-Body und Authentifizierung in einer einzigen Oberfläche. Sie können über diesen Node eine Verbindung zu jeder internen oder externen REST-API herstellen.
Das Konfigurationspanel des HTTP Request Nodes ist im Wesentlichen eine vollständige HTTP-Client-Oberfläche. Im Method-Feld können Sie GET, POST, PUT, PATCH, DELETE oder HEAD wählen. Im URL-Feld können Sie eine statische Adresse eingeben oder mit n8n-Expressions eine dynamische URL aus vorherigen Node-Ausgaben aufbauen — zum Beispiel ruft `https://api.example.com/users/{{ $json.userId }}` bei jeder Ausführung ein anderes Benutzerprofil ab.
Header, Query-Parameter und Request-Body werden in separaten Tabs verwaltet. Um einen JSON-Body zu senden, wählen Sie 'JSON' als Body Type und geben Key-Value-Paare ein oder schreiben direkt einen JSON-Ausdruck. Wechseln Sie in den 'Form Data'-Modus, um Formulardaten zu übermitteln. Der 'Binary'-Modus steht für Datei-Uploads und andere binäre Nutzdaten zur Verfügung.
| Parameter | Optionen / Hinweise | Typische Verwendung |
|---|---|---|
| Methode | GET, POST, PUT, PATCH, DELETE, HEAD | CRUD-Operationen |
| URL | Statisch oder dynamisch per Expression | Ressourcen-Endpoint |
| Header | Key-Value-Paare, Expression-fähig | Content-Type, Accept, benutzerdefinierte Header |
| Query Params | Key-Value-Paare | Filterung, Paginierung |
| Body Type | JSON, Form Data, Raw, Binary | Daten senden |
| Authentifizierung | None, Credential (vordefiniert) | API-Sicherheit |
| Timeout | In Millisekunden | Lang laufende API-Antworten |
| Retry On Fail | Ein/Aus, Anzahl Versuche | Wiederherstellung bei Fehlern |
Durch Aktivieren von 'Send Query Parameters' und 'Send Headers' werden zusätzliche Felder angezeigt. Da diese Felder Expressions unterstützen, können Sie dynamische Werte aus vorherigen Nodes direkt verwenden. Sie können beispielsweise eine Liste von Datensätzen aus einer Datenbankabfrage durchiterieren und für jeden Datensatz einen separaten API-Aufruf durchführen — mit dem SplitInBatches-Node von n8n, um Rate Limits einzuhalten.
Authentifizierung und Credentials: API-Key, OAuth2, Header Auth
n8n speichert Anmeldedaten verschlüsselt und ermöglicht die Wiederverwendung von Credential-Objekten in mehreren Workflows. Unterstützte Typen: API-Key, Header Auth, Basic Auth und OAuth2 (Authorization Code und Client Credentials).
In n8n werden Anmeldedaten in einem zentralen Credentials-Manager gespeichert. Jeder Credential wird in einer verschlüsselten Datenbank gehalten und von Workflows als Referenz aufgerufen — er wird nie direkt in die Node-Konfiguration eingebettet. Dies ist sowohl aus Sicherheits- als auch aus Wartungsgründen vorteilhaft: Wenn sich Ihr API-Key ändert, aktualisieren Sie ihn an einer einzigen Stelle, und alle Workflows, die diesen Key verwenden, werden automatisch aktualisiert.
| Authentifizierungstyp | Anwendungsfall | n8n-Einstellungen |
|---|---|---|
| API-Key | Statischer Schlüssel als Header oder Query-Parameter | Key-Name und -Wert; Position 'Header' oder 'Query' |
| Header Auth | Authentifizierung über benutzerdefinierten Header-Namen und -Wert | Header-Name und -Wert (z. B. X-API-Token) |
| Basic Auth | HTTP Basic mit Benutzername/Passwort | Felder Benutzername und Passwort |
| OAuth2 (Auth Code) | Benutzergenehmigter Zugriff (Drittanbieter-Dienste) | Client ID, Secret, Auth/Token URL, Scope |
| OAuth2 (Client Credentials) | Server-zu-Server (M2M) Zugriff | Client ID, Secret, Token URL |
Die OAuth2-Unterstützung ist eine der leistungsstärksten Funktionen von n8n. Im Authorization Code Flow verwaltet n8n die browserbasierte Autorisierungs-Weiterleitung; wenn das Access Token abläuft, erneuert es n8n automatisch im Hintergrund mit dem Refresh Token. So können OAuth2-basierte Unternehmensdienste wie Google Workspace, Microsoft 365 oder Salesforce ohne manuelles Token-Management in Workflows integriert werden. Für die Abstimmung mit Unternehmens-Sicherheitsrichtlinien empfehlen wir den n8n-Sicherheits- und Governance-Leitfaden.
Beim Erstellen eines Credentials überprüft die Schaltfläche 'Test Credential' dessen Gültigkeit vor dem Speichern. Diese Funktion erkennt Fehlkonfigurationen frühzeitig und verhindert Zeitverlust bei Workflow-Tests.
Datentransformation: JSON, Expressions und der Code Node
Um API-Antworten in Workflow-Daten zu transformieren, verwenden Sie n8n-Expressions (doppelte geschweifte Klammern) oder den Code Node (JavaScript oder Python). Expressions bewältigen einfache Feld-Zuordnungen; der Code Node übernimmt komplexe Transformationslogik.
Die vom HTTP Request Node zurückgegebene JSON-Antwort wird automatisch an nachfolgende Nodes weitergegeben. n8ns Expression-Engine ermöglicht den Zugriff auf tief verschachtelte JSON-Strukturen per Dot-Notation und Array-Indizierung — zum Beispiel `{{ $json.data.items[0].name }}`. Sie lesen aus dem aktuellen Node-Output mit `$json`, greifen auf alle Items mit `$items()` zu und referenzieren Workflow-Variablen mit `$vars`.
Für komplexe Datentransformationen ist der Code Node (früher Function Node) das Mittel der Wahl. Er bietet eine vollständige JavaScript- oder Python-Umgebung: Arrays filtern, Objekte umstrukturieren, Datumsformate konvertieren oder Daten aus mehreren Quellen zusammenführen. Der Code Node ist in jeder Situation eine leistungsstarke Alternative, in der die Standard-Expression-Engine von n8n nicht ausreicht.
- {{ $json.fieldName }} — Feld aus dem aktuellen Item lesen
- {{ $json.nested.object.value }} — Zugriff auf verschachteltes JSON
- {{ $items('NodeName')[0].json.field }} — Ausgabe eines bestimmten Nodes abrufen
- {{ $now.format('YYYY-MM-DD') }} — Datums-/Zeitausdrücke
- Code Node: return items.map(item => ({ json: { id: item.json.id, name: item.json.name } })) — Item-Transformation
Bei der Verarbeitung großer Datensätze verwenden Sie SplitInBatches, um Daten in Chunks aufzuteilen; führen Sie pro Batch einen HTTP-Request-Aufruf durch, um den Speicherverbrauch zu optimieren und API-Rate-Limits einzuhalten. Für intelligente Datenzuordnung und KI-gestützte Transformationen lesen Sie den n8n KI-Agenten-Einrichtungsleitfaden.
Fehlerbehandlung und Wiederholungen: Retry On Fail und Error Workflows
Die Option 'Retry On Fail' am HTTP Request Node wiederholt automatisch bei vorübergehenden Netzwerkfehlern oder 5xx-Antworten. Für kritische Workflows automatisiert ein dedizierter Error Workflow Fehlerbenachrichtigungen und kompensierende Aktionen.
In der Produktion begegnen API-Integrationen unweigerlich vorübergehenden Fehlern: Netzwerk-Timeouts, Rate Limiting (429) oder temporäre Serverfehler (503). n8n bietet eine 'Retry On Fail'-Option auf Ebene des HTTP Request Nodes. Wenn aktiviert, legen Sie die maximale Anzahl von Versuchen und die Wartezeit zwischen den Versuchen (in Millisekunden) fest. Exponentielles Backoff kann durch Hinzufügen eines Wait Nodes zwischen den Wiederholungen simuliert werden.
Über die node-seitige Fehlerbehandlung hinaus bietet n8n auch workflow-seitige Fehlerverwaltung. Sie können für jeden Workflow einen 'Error Workflow' definieren; tritt im Haupt-Workflow ein nicht behandelter Fehler auf, wird dieser dedizierte Workflow automatisch ausgelöst. Der Error Workflow empfängt die Fehlermeldung und den Kontext über `$execution.error` und ermöglicht so die Automatisierung kompensierender Aktionen wie das Senden einer Slack-Benachrichtigung, das Schreiben des fehlgeschlagenen Datensatzes in eine Datenbank oder das Benachrichtigen eines Administrators per E-Mail.
- HTTP Request Node > Settings > Retry On Fail: Aktiviert
- Max Tries: 3–5 (5 für kritische Integrationen)
- Wait Between Tries: 1000–5000 ms (je nach API-Rate-Limit)
- Settings > On Error: 'Continue' vs. 'Stop And Error' abwägen
- Workflow-Ebene: Settings > Error Workflow — Fehlerbehandlungs-Workflow verknüpfen
- Im Error Workflow: Benachrichtigungs-Node (Slack, E-Mail) + Logging-Node (Datenbank oder Logdatei)
Rate-Limit-Verwaltung ist besonders bei Massenoperationen kritisch. Wird die erlaubte Anzahl an Anfragen pro Sekunde oder Minute überschritten, erhalten Sie einen 429-Fehler. Um dies zu verhindern, begrenzen Sie mit SplitInBatches die Batch-Größe und fügen Sie zwischen den Batches einen Wait Node ein, damit Massenverarbeitungsszenarien sicher innerhalb der API-Limits ausgeführt werden können.
Praxisbeispiel: Schrittweise Integration einer eigenen API
Um eine eigene oder geschlossene API in n8n zu integrieren: Daten mit Webhook Trigger empfangen, API mit HTTP Request Node aufrufen, Antwort mit Code Node transformieren und Fehlerbehandlung hinzufügen. Dieses Muster gilt für jeden Dienst ohne nativen Connector.
Gehen wir ein reales Szenario durch: Ein internes ERP-System ruft einen n8n-Webhook auf, wenn eine neue Bestellung erstellt wird. Der Workflow erfasst dieses Ereignis, leitet die Bestelldetails an eine externe Logistik-API weiter, ruft die Tracking-Nummer aus der Antwort ab und sendet sie an das Kundenbenachrichtigungssystem. Keiner dieser drei Dienste hat einen nativen n8n-Connector — alle kommunizieren jedoch über HTTP.
- Webhook Trigger: empfängt POST-Anfrage vom ERP (Bestell-JSON). Pfad: /webhook/neue-bestellung. Authentifizierung: Header Auth (X-ERP-Secret).
- HTTP Request (Logistik-API): POST https://api.logistik.example.com/v1/shipments. Body: JSON aus ERP-Bestelldaten. Auth: API-Key (Header: Authorization: Bearer {{credential}}). Retry On Fail: An, Max 3.
- Code Node: extrahiert tracking_number und estimated_delivery aus der Logistik-API-Antwort; kombiniert mit Kunden-E-Mail-Adresse zu Benachrichtigungs-Payload.
- HTTP Request (Benachrichtigungs-API): POST https://api.benachrichtigung.example.com/send. Body: Payload aus Code Node. Auth: Basic Auth.
- Error Workflow: Bei einem Fehler in einem beliebigen Schritt wird eine Slack-Benachrichtigung gesendet und die fehlgeschlagene Bestell-ID in der Datenbank protokolliert.
Dieses Muster deckt die große Mehrheit der Unternehmensautomatisierungsszenarien ab. Für komplexere Fälle — mehrstufige OAuth2-Autorisierung, asynchrone APIs, Hybridarchitekturen mit Webhooks und Polling — verweisen wir auf den Leitfaden für unternehmensweite n8n-Anwendungsfälle. Wenn Sie Ihren Integrationen KI-Fähigkeiten hinzufügen möchten, bietet der n8n KI-Agenten-Einrichtungsleitfaden einen umfassenden Einstiegspunkt.
n8ns Flexibilität macht es möglich, jedes System, das über HTTP kommuniziert — cloudbasierte SaaS-Lösungen, On-Premises-Legacy-Systeme oder IoT-Geräte — in einen Workflow einzubinden. Verschlüsselte Credential-Verwaltung, rollenbasierte Zugriffskontrolle und Audit-Logs stellen sicher, dass Unternehmens-Sicherheitsanforderungen erfüllt werden.
Häufig gestellte Fragen
Was ist ein Webhook und wie funktioniert er in n8n?
Ein Webhook ist ein Mechanismus, bei dem eine Anwendung bei einem bestimmten Ereignis eine HTTP-Anfrage an eine andere URL sendet. In n8n stellt der Webhook Trigger Node eine URL bereit, die auf diese Anfragen wartet; jede eingehende Anfrage startet den Workflow automatisch.
Was macht der HTTP Request Node und mit welchen APIs kann er verwendet werden?
Der HTTP Request Node sendet eine Anfrage aus einem n8n-Workflow an einen beliebigen HTTP/HTTPS-Endpoint. Er funktioniert mit jedem Dienst, der den REST-API-Standard unterstützt, und ist die primäre Integrationsmethode für eigene, unternehmenseigene oder geschlossene APIs ohne nativen n8n-Connector.
Wie wird die API-Authentifizierung in n8n gehandhabt?
Im Credentials-Manager wird ein Credential-Objekt erstellt, wobei einer der unterstützten Typen gewählt wird: API-Key, Header Auth, Basic Auth oder OAuth2. Dieser Credential wird dann im HTTP Request Node ausgewählt und automatisch auf alle Anfragen angewendet; Anmeldedaten werden verschlüsselt gespeichert.
Unterstützt n8n OAuth2? Ist die Token-Erneuerung automatisch?
Ja, n8n unterstützt OAuth2 Authorization Code und Client Credentials. Wenn das Access Token abläuft, verwendet n8n im Hintergrund automatisch den Refresh Token, um ein neues zu erhalten; der Workflow läuft ohne Unterbrechung und ohne manuelle Eingriffe weiter.
Wie verwalte ich API-Rate-Limits in n8n?
Verwenden Sie SplitInBatches, um Massenanfragen in Chunks aufzuteilen, und fügen Sie zwischen den Batches einen Wait Node hinzu, um das erlaubte Rate-Limit der API einzuhalten. Die Option Retry On Fail am HTTP Request Node wiederholt automatisch bei 429-Fehlern.
Wie funktioniert die Fehlerbehandlung für den HTTP Request Node in n8n?
Retry On Fail kann auf Node-Ebene aktiviert werden. Auf Workflow-Ebene definieren Sie einen Error Workflow, um nicht behandelte Fehler zu verarbeiten — Slack-Benachrichtigungen senden, fehlgeschlagene Datensätze in einer Datenbank protokollieren oder kompensierende Aktionen automatisch auslösen.
Kann ich eine On-Premises- oder geschlossene API mit n8n integrieren?
Ja. Der HTTP Request Node funktioniert mit jeder über URL erreichbaren API. Bei einem selbst gehosteten n8n-Deployment kann n8n, wenn es auf einem Server mit Zugang zum internen Netzwerk installiert ist, auch private APIs hinter VPN oder Firewall aufrufen.
Kann ich Webhook und HTTP Request Node im selben Workflow verwenden?
Ja, das ist ein gängiges Muster. Der Webhook Trigger empfängt Daten von außen, und ein oder mehrere HTTP Request Nodes im Workflow senden Anfragen an verschiedene APIs. So können Mehrfach-System-Integrationen in einem einzigen Workflow orchestriert werden.
Fazit
Gemeinsam ermöglichen n8ns Webhook Trigger und HTTP Request Node die Einbindung jedes HTTP-basierten Dienstes in einen Workflow. Für eigene, unternehmenseigene oder geschlossene APIs ohne native Connectors bieten diese beiden Nodes eine flexible und sichere Integrationsgrundlage. Verschlüsselte Credential-Verwaltung, OAuth2-Unterstützung und automatische Token-Erneuerung erfüllen Unternehmens-Sicherheitsanforderungen und steigern gleichzeitig die Entwicklerproduktivität.
Retry-Logik, Fehlerbehandlung und Error Workflows machen Ihre Integrationen produktionsreif. Für branchenspezifische Integrationsszenarien und die Konfiguration der n8n-Infrastruktur in Unternehmensmaßstab steht das Sora-Integrationsteam für ein kostenloses Erstgespräch zur Verfügung.