> ## Content Index > Fetch the complete content index at: https://relvro.de/llms.txt > Use this file to discover other available public pages before exploring further. # n8n HTTP Request: API verbinden, Daten abrufen & senden - URL: https://relvro.de/n8n-http-request/ - Published: 2026-10-01T00:21:25.000Z - Updated: 2026-10-27T19:23:31.000Z - Author: ILYAS‬‏ - Tags: Automation 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: ```text 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: ```text GET /users ``` ### POST `POST` wird häufig verwendet, um neue Daten zu erstellen oder eine Aktion auszulösen. Beispiel: ```text 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: ```text 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: ```text https://api.example.com/users?limit=10 ``` Dabei ist: ```text 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: ```text 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: ```text https://api.example.com/users ``` Für einen einfachen Abruf kannst du im HTTP Request Node beispielsweise konfigurieren: ```text 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: ```text limit = 10 ``` Der Request entspricht dann sinngemäß: ```text 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: ```json { "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: ```json { "name": "Anna", "email": "anna@example.com" } ``` Wenn Werte aus vorherigen n8n-Nodes übernommen werden sollen, kannst du Expressions beziehungsweise Data Mapping verwenden. Beispielsweise: ```text {{ $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: ```text 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: ```bash 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: ```text 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](https://docs.n8n.io/build/code-in-n8n/cookbook/http-request-node/pagination.md?ref=relvro.de) ## 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: ```text 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: 1. Wo läuft n8n? 2. Wo läuft die API? 3. Auf welchem Host und Port lauscht die API? 4. 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](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest?ref=relvro.de) **HTTP Request Credentials:** [n8n HTTP Request Credentials](https://docs.n8n.io/integrations/builtin/credentials/httprequest?ref=relvro.de) **Custom API Operations:** [n8n Custom API Operations](https://docs.n8n.io/integrations/builtin/custom-api-actions-for-existing-nodes?ref=relvro.de) **HTTP Request Pagination:** [n8n HTTP Request Node – Pagination](https://docs.n8n.io/build/code-in-n8n/cookbook/http-request-node/pagination.md?ref=relvro.de) **HTTP Request – Common Issues:** [n8n HTTP Request – Common Issues](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/common-issues?ref=relvro.de) ### Weiterführend bei RELVRO Wenn du mit n8n arbeitest, können auch diese beiden Artikel relevant sein: - [n8n AI Agent](https://relvro.de/n8n-ai-agent/) - [n8n Cloud vs. Self-hosted](https://relvro.de/n8n-cloud-self-hosted/)