Begriff

HTTP Request Node (n8n)

AI-Automation Networking S2

2 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Der HTTP Request Node ist die Universal-Fernbedienung von n8n. n8n hat für viele Apps (Google, Slack, Notion) fertige Bausteine. Aber nicht für alle. Es gibt Millionen von Software-Tools da draußen. Mit dem HTTP Request Node kannst du jeden Dienst der Welt ansteuern, der eine API hat.

Es ist, als hättest du einen Universal-Stecker.

Du willst das Wetter von einer Nischen-Seite abrufen? -> HTTP Request.
Du willst Daten an deine deutsche Buchhaltungs-Software senden? -> HTTP Request.
Du willst eine KI ansprechen, für die es noch keinen Node gibt? -> HTTP Request.

Merksatz: Das Schweizer Taschenmesser, um mit dem Rest des Internets zu sprechen.

Das Wichtigste ist, die API-Dokumentation des anderen Dienstes zu lesen. Der Node funktioniert genau wie ein Browser oder Postman:

URL: Wohin soll die Reise gehen? (z. B. https://api.wetter.de/berlin).
Method: Was willst du tun?
- GET: Daten lesen (Wetter abrufen).
- POST: Daten senden (Neuen Kunden anlegen).
Authentication: Wer bist du?
- Hier wählst du deine "Credentials" aus (z. B. Bearer Token), damit n8n dich automatisch einloggt.

Tipp: Wenn es für eine App keinen fertigen Node gibt, google einfach "App-Name API". Wenn sie eine REST-API haben, kannst du sie mit diesem Node steuern.

1. Daten senden (Body & Query)

Query Parameters: Alles was hinter das ? in der URL kommt (?stadt=Berlin&lang=de). In n8n gibt es dafür ein extra Feld "Send Query Parameters".
Body: Bei POST-Requests sendest du Daten mit. Meistens als JSON. Du kannst in n8n entweder Felder einzeln definieren oder "Raw JSON" wählen und direkt { "name": "{{ $json.name }}" } eingeben.

2. Pagination (Seitenweise laden)

APIs liefern oft nicht alles auf einmal. "Gib mir alle Kunden" -> Die API liefert nur die ersten 50. Du müsstest normalerweise eine Schleife bauen ("Gib mir Seite 2, Seite 3..."). Der HTTP Request Node hat eine eingebaute Pagination-Funktion. Du sagst ihm: "Guck in die Antwort, ob da eine 'next_page_url' steht. Wenn ja, ruf die automatisch auf und klebe alle Ergebnisse zusammen." Das spart dir Stunden an komplexer Logikbauerei!

3. Error Handling

Wenn die API 404 oder 500 zurückgibt, bricht n8n normalerweise ab. Du kannst im Node unter "Settings" -> "On Error: Continue" aktivieren. Dann gibt der Node stattdessen ein JSON aus: { "error": true, "message": "Not found" }. Dein Workflow läuft weiter, und du kannst mit einem IF-Node darauf reagieren ("Wenn Fehler, dann sende Nachricht an Admin").

Mutual TLS (mTLS) und SSL-Offloading

Der HTTP Node kann nicht nur Server-Zertifikate auslesen. In Zero-Trust Enterprise Setups (wie API-Gateways bei Banken) verlangt der Zielserver mTLS (Mutual TLS). Das bedeutet, n8n (der Client) muss beim Handshake ebenfalls ein Zertifikat und einen Private-Key vorzeigen (Client Certificate). Das konfiguriert man im Node unter SSL/TLS Options -> Client Certificates. Zusätzlich umgeht ein Hardcore-Dev das OS-Trust-System, indem er Ignore SSL Issues nutzt (nur zum Debuggen!) oder, die weitaus sauberere Lösung, Custom CA-Certificates (NODE_EXTRA_CA_CERTS) per Docker Volume-Mount injiziert, um von n8n aus durch Deep-Packet-Inspection Firewalls des Firmennetzes (NetScaler, F5) ohne Handshake-Errors durchzufunken.

Proxy Hopping & SOCKS5

Wenn n8n (hosted in AWS USA) eine interne On-Premise API (im Rechenzentrum Frankfurt) per HTTP-Request erreichen muss, baut man nicht einfach Ports ins freie Internet. n8n bietet systemweite Proxy-Unterstützung an (HTTP_PROXY, HTTPS_PROXY in .env). Dieser Request aus dem Node wird transparent durch einen Squid-Cachingserver oder einen SOCKS5-Tunnel gejagt. Ein spezieller Reverse-Tunnel (wie Cloudflare Tunnels/ngrok) leitet die Kommunikation kryptographisch abgesichert, ohne Ingress-DDoS-Gefahr, direkt bis zum Dark-Site-Server durch. Der HTTP-Node agiert vorschriftsmäßig, aber die IP auf IP-Ebene wird von Proxies maskiert (anonymisiertes Web-Scraping gegen Rate-Limits ist so via Rotating-Proxies ebenfalls machbar).

Binary Streams & Memory-Limits (Backpressure)

Standardmäßig wird der Body (Payload) einer API-Antwort als JSON ins RAM des NodeJS-Workers deserialisiert. Liest du via HTTP Request Node einen 4 GB Datenbank-Dump an, stürzt n8n mit FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed unweigerlich ab. Die Erlösung lautet Stream-Response. Stellt man Node-Response auf File, schreibt Axios den eingehenden TCP-Stream (Chunk for Chunk) radikal auf das lokale oder assoziierte S3 Volume (Backing Store), ohne den V8-Heap zu verstopfen. Erst später, im "Read Binary File" Node, nutzt man Event-Listener oder Line-Reader, um das Monster-Dokument stückweise, ohne Memory-Blockade, weiterzuverarbeiten.

Quick-Check

Wann solltest du den HTTP Request Node nutzen, statt des fertigen (z. B. Slack) Nodes?
Wenn der fertige Node eine ganz neue Funktion der App noch nicht unterstützt oder wenn du mit einer App sprichst, für die es gar keinen fertigen Node gibt.
Was bedeutet "Pagination" bei APIs?
Das Aufteilen großer Datenmengen auf mehrere "Seiten". Der HTTP-Node kann diese Seiten automatisch nacheinander abrufen und zusammenfügen.
Warum ist es sicherer, "Credentials" in n8n zu speichern, statt den API-Key direkt in die URL zu schreiben?
Weil Credentials verschlüsselt gespeichert werden und beim Export des Workflows (Teilen mit Freunden) automatisch entfernt werden. Ein Key in der URL wäre für jeden sichtbar.