Inhalt
Der HTTP Request Node gehört zu den wichtigsten Bausteinen in n8n, wenn du Daten mit einer API austauschen möchtest. Du kannst damit Daten abrufen, senden, aktualisieren oder löschen – auch dann, wenn n8n für den gewünschten Dienst keinen eigenen Node anbietet.
Für die Arbeit mit APIs brauchst du dabei vor allem ein Verständnis für HTTP-Methoden, URLs, Query-Parameter, Header, Authentifizierung und Request-Bodies.
Dieser Artikel zeigt dir, wie du einen HTTP Request in n8n aufbaust, welche typischen Fehler auftreten und worauf du bei APIs achten solltest.
Kurz erklärt: Was ist der HTTP Request Node?
Mit dem HTTP Request Node kannst du aus einem n8n-Workflow heraus HTTP-Anfragen an eine API senden.
Ein typischer Request besteht aus mehreren Bausteinen:
- HTTP-Methode
- URL beziehungsweise Endpoint
- Query-Parameter
- Header
- Authentifizierung
- Request Body
- Verarbeitung der Antwort
Der Node unterstützt unter anderem GET, POST, PUT, PATCH und DELETE. n8n dokumentiert außerdem weitere HTTP-Methoden wie HEAD und OPTIONS.
Das macht den HTTP Request Node besonders nützlich, wenn du mit einem Dienst arbeiten möchtest, für den es keinen passenden fertigen n8n-Node gibt.
Wann solltest du HTTP Request verwenden?
Der Node ist besonders interessant, wenn du:
- eine REST-API direkt ansprechen möchtest
- Daten aus einem externen Dienst abrufen willst
- Daten an eine API senden möchtest
- eine API aktualisieren oder löschen möchtest
- einen Dienst ohne passenden n8n-Node integrieren willst
- einen vorhandenen cURL-Request in n8n übernehmen möchtest
- einen API-Endpunkt mit eigenen Parametern oder Headern aufrufen musst
Eine fertige n8n-Integration kann trotzdem die einfachere Lösung sein, wenn sie die benötigte Funktion bereits vollständig abdeckt.
Der HTTP Request Node ist vor allem dann interessant, wenn du mehr Kontrolle über den eigentlichen API-Aufruf brauchst.
Einen API-Request richtig aufbauen
Bevor du einen Request konfigurierst, solltest du die Dokumentation der API prüfen.
Dort findest du normalerweise:
- den Endpoint
- die erlaubte HTTP-Methode
- benötigte Parameter
- erforderliche Header
- Authentifizierung
- das erwartete Format des Request Bodys
- mögliche Antwortformate
- Fehlercodes
- gegebenenfalls Pagination-Regeln
Ein einfacher Request kann beispielsweise so aussehen:
GET https://api.example.com/users
Die URL allein reicht bei vielen APIs allerdings nicht aus. Je nach Dienst können zusätzliche Parameter oder eine Authentifizierung erforderlich sein.
Die wichtigsten Bestandteile
Method: Welche Aktion soll ausgeführt werden?
URL: Welchen API-Endpunkt möchtest du aufrufen?
Query Parameters: Welche zusätzlichen Werte sollen an die URL übergeben werden?
Headers: Welche Metadaten oder Authentifizierungsinformationen benötigt die API?
Body: Welche Daten möchtest du bei einem Request an den Server senden?
Authentication: Wie weist du dich gegenüber der API aus?
Diese Bestandteile solltest du nicht unabhängig voneinander betrachten. Die API-Dokumentation gibt vor, welche Kombination benötigt wird.
Die wichtigsten HTTP-Methoden
Die HTTP-Methode beschreibt, was mit der Anfrage gemacht werden soll.
GET
GET wird typischerweise verwendet, um Daten abzurufen.
Beispiel:
GET /users
POST
POST wird häufig verwendet, um neue Daten zu erstellen oder eine Aktion auszulösen.
Beispiel:
POST /users
Dabei wird häufig ein Request Body mitgesendet.
PUT
PUT wird verwendet, um eine Ressource vollständig zu ersetzen oder entsprechend der API zu aktualisieren.
PATCH
PATCH wird häufig verwendet, um nur bestimmte Eigenschaften einer Ressource zu ändern.
DELETE
DELETE wird verwendet, um eine Ressource zu löschen.
Welche Methode tatsächlich verwendet werden muss, bestimmt immer die jeweilige API. Du solltest deshalb nicht allein anhand des gewünschten Ergebnisses raten, sondern die API-Dokumentation prüfen.
URL, Query-Parameter und Header
URL
Die URL bezeichnet den API-Endpunkt, den du aufrufen möchtest.
Beispiel:
https://api.example.com/users
Ein falscher Endpoint führt häufig zu einem 404-Fehler.
Query-Parameter
Query-Parameter werden an eine URL angehängt oder im HTTP Request Node separat konfiguriert.
Beispiel:
https://api.example.com/users?limit=10
Dabei ist:
limit=10
ein Query-Parameter.
In n8n kannst du Query-Parameter über Send Query Parameters konfigurieren.
Bei APIs, die Arrays erwarten, kann außerdem das verwendete Array-Format relevant sein. n8n unterstützt dafür beispielsweise:
- No Brackets
- Brackets Only
- Brackets with Indices
Welche Variante benötigt wird, hängt von der jeweiligen API ab.
Header
Header enthalten zusätzliche Informationen über den Request.
Ein häufiger Header ist beispielsweise:
Content-Type: application/json
APIs können außerdem einen Authorization-Header oder andere spezifische Header verlangen.
API-Authentifizierung in n8n
Viele APIs verlangen eine Authentifizierung.
n8n unterstützt dafür verschiedene Möglichkeiten. Dazu gehören unter anderem:
- Basic Auth
- Header Auth
- Digest Auth
- OAuth1
- OAuth2
- Query Auth
- Custom Auth
- Simplified Custom Auth
Wenn n8n für einen Dienst einen Predefined Credential Type anbietet, empfiehlt die offizielle Dokumentation, diesen zu verwenden.
Bei APIs ohne passende vordefinierte Integration kannst du generische Credentials konfigurieren.
Wichtig ist dabei, die Authentifizierung nicht einfach nach einem allgemeinen Muster einzurichten. Die API-Dokumentation legt fest, welche Methode und welche Zugangsdaten erforderlich sind.
Praxisbeispiel: Einen GET-Request aufbauen
Angenommen, eine API stellt Benutzerdaten unter diesem Endpoint bereit:
https://api.example.com/users
Für einen einfachen Abruf kannst du im HTTP Request Node beispielsweise konfigurieren:
Method: GET
URL: https://api.example.com/users
Wenn die API zusätzliche Parameter benötigt, kannst du diese über Send Query Parameters ergänzen.
Zum Beispiel:
limit = 10
Der Request entspricht dann sinngemäß:
GET https://api.example.com/users?limit=10
Wenn die API eine Authentifizierung verlangt, musst du diese zusätzlich konfigurieren.
Die konkrete Antwort hängt von der API ab. Eine JSON-Antwort könnte beispielsweise so aussehen:
{
"users": [
{
"id": 1,
"name": "Anna"
},
{
"id": 2,
"name": "Max"
}
]
}
Die nachfolgenden n8n-Nodes können diese Daten anschließend weiterverarbeiten.
JSON-Daten senden
Viele APIs erwarten bei POST, PUT oder PATCH einen JSON-Body.
Aktiviere dafür im HTTP Request Node Send Body und wähle als Body Content Type beispielsweise JSON.
Ein einfacher Body könnte so aussehen:
{
"name": "Anna",
"email": "anna@example.com"
}
Wenn Werte aus vorherigen n8n-Nodes übernommen werden sollen, kannst du Expressions beziehungsweise Data Mapping verwenden.
Beispielsweise:
{{ $json.name }}
Damit wird der Wert aus dem aktuellen Input-Item verwendet.
Die genaue Struktur des JSON-Bodys muss allerdings zur API passen. Ein syntaktisch korrektes JSON ist nicht automatisch ein gültiger Request für den jeweiligen Dienst.
Daten aus einer API weiterverwenden
Der HTTP Request Node ist normalerweise nicht das Ende des Workflows.
Eine typische Struktur kann beispielsweise so aussehen:
Webhook
↓
HTTP Request
↓
Daten verarbeiten
↓
Google Sheets / Datenbank / CRM
Der HTTP Request Node liefert die Antwort an den nächsten Schritt des Workflows.
Du kannst beispielsweise:
- einzelne Felder auswählen
- Daten umwandeln
- Bedingungen prüfen
- Datensätze filtern
- Ergebnisse speichern
- weitere APIs aufrufen
Wenn eine API beispielsweise eine Benutzer-ID liefert, kann diese ID anschließend als Eingabe für einen weiteren Request verwendet werden.
Damit entsteht aus einem einzelnen API-Aufruf ein vollständiger Datenfluss.
cURL in n8n übernehmen
Viele API-Dokumentationen enthalten fertige cURL-Beispiele.
n8n kann solche cURL-Befehle direkt in den HTTP Request Node importieren.
Beispiel:
curl https://api.example.com/users \
-H "Authorization: Bearer TOKEN"
Im HTTP Request Node kannst du über Import cURL den entsprechenden Befehl einfügen.
n8n übernimmt daraus die Request-Konfiguration.
Wichtig: Beim Import werden Parameterwerte laut n8n-Dokumentation als Strings übernommen. Wenn Zahlen oder Boolean-Werte ihre ursprünglichen Datentypen behalten sollen, solltest du die Konfiguration anschließend entsprechend prüfen.
Der Import überschreibt außerdem eine bereits vorhandene Konfiguration des Nodes.
Pagination: Wenn eine API mehrere Seiten zurückgibt
Viele APIs liefern große Datenmengen nicht in einer einzigen Antwort zurück.
Stattdessen bekommst du beispielsweise:
Seite 1 → 100 Datensätze
Seite 2 → 100 Datensätze
Seite 3 → 100 Datensätze
In diesem Fall brauchst du Pagination.
n8n bietet im HTTP Request Node verschiedene Pagination-Modi. Dazu gehören unter anderem:
- Off
- Update a Parameter in Each Request
- Response Contains Next URL
Welcher Modus geeignet ist, hängt davon ab, wie die jeweilige API ihre Seiten strukturiert.
n8n stellt für Pagination außerdem Variablen wie $pageCount, $request und $response bereit.
Bevor du Pagination konfigurierst, solltest du die Antwort der API einmal ohne Pagination prüfen. Du musst wissen, ob die API beispielsweise eine Seitennummer, einen Cursor oder eine URL für die nächste Seite zurückgibt.
Die offizielle n8n-Dokumentation enthält dafür ein eigenes Beispiel:
n8n HTTP Request Node – Pagination
Typische Fehler beim HTTP Request
HTTP-Fehler bedeuten nicht automatisch, dass n8n selbst das Problem verursacht.
Häufig liegt die Ursache in der Request-Konfiguration oder auf Seiten der API.
400 Bad Request
Ein 400 bedeutet normalerweise, dass der Server die Anfrage nicht wie erwartet verarbeiten konnte.
Mögliche Ursachen:
- falsche Parameter
- ungültige Parameterwerte
- falsches Array-Format
- fehlerhafter Request Body
Prüfe deshalb zuerst die API-Dokumentation und vergleiche deinen Request mit einem funktionierenden Beispiel.
401 Unauthorized
Ein 401 deutet häufig auf ein Problem mit der Authentifizierung hin.
Prüfe:
- API-Key
- Token
- Credential-Konfiguration
- Authentifizierungsmethode
- erforderliche Header
403 Forbidden
Bei 403 wurde die Anfrage verstanden, aber der Zugriff ist nicht erlaubt.
Mögliche Gründe sind fehlende Berechtigungen, ein eingeschränkter API-Key oder fehlende Scopes.
404 Not Found
Ein 404 bedeutet häufig, dass der angeforderte Endpoint nicht gefunden wurde.
Prüfe:
- URL
- Schreibfehler
- API-Version
- Endpoint
- veraltete oder entfernte API-Pfade
429 Too Many Requests
Ein 429 bedeutet, dass zu viele Anfragen gesendet wurden oder ein Rate Limit erreicht wurde.
Bei größeren Datenmengen können Batch-Verarbeitung und angemessene Abstände zwischen Requests helfen. n8n bietet dafür unter anderem Optionen zur Batching-Konfiguration.
Je nach Workflow kann außerdem eine Retry-Strategie sinnvoll sein.
Was bedeutet ECONNREFUSED?
ECONNREFUSED ist etwas anderes als ein klassischer HTTP-Statuscode.
Die Verbindung zum Zielhost wurde erreicht, aber am angesprochenen Port nimmt kein Dienst die Verbindung an.
Das kann beispielsweise passieren, wenn:
- ein lokaler Dienst nicht läuft
- der falsche Port verwendet wird
- ein Container nicht erreichbar ist
- der Dienst nur auf einer anderen Adresse lauscht
Die genaue Umgebung ist dabei wichtig.
Warum localhost bei APIs problematisch sein kann
Ein häufiger Fehler entsteht bei lokalen APIs und Docker.
Wenn n8n selbst in einem Docker-Container läuft, bedeutet:
localhost
nicht automatisch deinen Host-Computer.
localhost beziehungsweise 127.0.0.1 verweist innerhalb des Containers auf den Container selbst.
Wenn sich der gewünschte Dienst auf dem Host-System befindet, kann die passende Adresse von der verwendeten Umgebung abhängen. Bei Docker Desktop kann beispielsweise host.docker.internal relevant sein.
Wenn beide Dienste im selben Docker-Compose-Netzwerk laufen, wird häufig der entsprechende Service-Name verwendet.
Bei einer selbst gehosteten Umgebung solltest du deshalb zuerst klären:
- Wo läuft n8n?
- Wo läuft die API?
- Auf welchem Host und Port lauscht die API?
- Können beide Systeme miteinander kommunizieren?
n8n Cloud und lokale APIs
Bei n8n Cloud kannst du nicht einfach auf einen Dienst zugreifen, der nur auf deinem lokalen Rechner über localhost erreichbar ist.
Der Cloud-Workflow läuft in der Infrastruktur von n8n.
Ein ausschließlich lokal erreichbarer Dienst muss deshalb über einen entsprechend erreichbaren Endpoint verfügbar gemacht werden, wenn n8n Cloud darauf zugreifen soll.
HTTP Request oder fertige n8n-Integration?
Der HTTP Request Node ist flexibel, aber nicht immer die einfachste Lösung.
Wenn n8n bereits einen passenden Node für den gewünschten Dienst anbietet und dieser alle benötigten Funktionen abdeckt, kann die fertige Integration weniger Konfiguration erfordern.
Der HTTP Request Node wird besonders interessant, wenn:
- keine passende Integration existiert
- ein bestimmter API-Endpunkt benötigt wird
- du eigene Parameter oder Header kontrollieren musst
- eine API-Funktion noch nicht über den vorhandenen Node abgedeckt wird
- du einen vorhandenen cURL-Request übernehmen möchtest
Die Frage lautet deshalb weniger, ob der HTTP Request Node leistungsfähiger ist, sondern welche Schnittstelle du tatsächlich brauchst.
Was du vor dem ersten Request prüfen solltest
Bevor du einen API-Request in n8n einrichtest, solltest du diese Punkte prüfen:
1. Endpoint
Ist die URL korrekt und aktuell?
2. HTTP-Methode
Verlangt die API GET, POST, PUT, PATCH oder eine andere Methode?
3. Authentifizierung
Welche Authentifizierung benötigt die API?
4. Query-Parameter
Welche Parameter sind erforderlich?
5. Header
Welche Header müssen gesetzt werden?
6. Request Body
Falls Daten gesendet werden: Welches Format erwartet die API?
7. Antwortformat
Welche Daten liefert die API zurück?
8. Fehlercodes
Welche Fehlercodes und Rate Limits sind dokumentiert?
9. Pagination
Gibt die API alle Ergebnisse auf einmal zurück oder musst du mehrere Seiten abrufen?
10. Netzwerk
Ist der API-Endpunkt von der Umgebung erreichbar, in der n8n läuft?
Diese Prüfung spart häufig mehr Zeit, als einen Request mehrfach mit unterschiedlichen Einstellungen auszuprobieren.
Fazit
Der HTTP Request Node macht n8n zu einer flexiblen Schnittstelle für APIs.
Du kannst damit:
- Daten abrufen
- Daten senden
- bestehende Daten aktualisieren
- Daten löschen
- APIs ohne eigenen n8n-Node anbinden
- cURL-Beispiele übernehmen
- Pagination konfigurieren
- API-Antworten in weiteren Workflow-Schritten verarbeiten
Die technische Herausforderung liegt dabei meistens nicht im Node selbst. Entscheidend ist, die Anforderungen der jeweiligen API korrekt in n8n abzubilden.
Wenn du Endpoint, Methode, Authentifizierung, Parameter, Header und Body sauber aus der API-Dokumentation ableitest, lässt sich der HTTP Request Node für sehr unterschiedliche Integrationsaufgaben einsetzen.
Offizielle n8n-Quellen
HTTP Request Node:
n8n HTTP Request Documentation
HTTP Request Credentials:
n8n HTTP Request Credentials
Custom API Operations:
n8n Custom API Operations
HTTP Request Pagination:
n8n HTTP Request Node – Pagination
HTTP Request – Common Issues:
n8n HTTP Request – Common Issues
Weiterführend bei RELVRO
Wenn du mit n8n arbeitest, können auch diese beiden Artikel relevant sein:
