n8n HTTP Request einrichten: JSON senden und prüfen

HTTP Request sendet, Webhook empfängt

Beide Nodes beschreiben unterschiedliche Seiten einer Verbindung. Der HTTP Request Node ruft eine Adresse auf. Der Webhook-Node wartet auf einen eingehenden Aufruf und startet dadurch seinen Workflow. Ein Workflow kann Daten empfangen und anschließend selbst eine weitere API ansprechen.

Für unser Beispiel kannst du einen kontrollierten Empfänger nach der Anleitung n8n Webhook einrichten vorbereiten. Die Testadresse muss erreichbar und ihr Testlistener eingeschaltet sein. Verwende für diesen ersten Aufruf keine Produktionsadresse, an der unbeabsichtigte Folgeaktionen ausgelöst werden.

Einen eigenen Testrequest aufbauen

Unser eigener Beispielvertrag sendet ein Lager-Testereignis mit der Kennung probe-002. Die Artikelnummer und Menge sind frei gewählte Übungsdaten; es wird kein echter Lagerbestand verändert. Stelle einen HTTP Request Node so ein:

1. Method: POST.
2. URL: Die vollständig kopierte Testadresse deines vorbereiteten Empfängers.
3. Authentication: Das vom Empfänger verlangte Verfahren mit dem passenden Credential.
4. Send Body: Einschalten; Body Content Type auf JSON und Specify Body auf Using JSON setzen.

{
  "event_id": "probe-002",
  "item_id": "ART-42",
  "quantity": 3
}

Vor dem Ausführen prüfst du im Editor Zieladresse und aufgelöste Werte. Das Beispiel ist ein entworfener Datenvertrag, kein importierbarer Komplettworkflow und keine hier gemessene Ausführung.

URL, Auth, Header und Body auseinanderhalten

Die Node-Referenz führt diese Parameter getrennt. Nutze die API-Dokumentation des Zielsystems als Vertrag. Ein GET-Aufruf zum Lesen benötigt andere Angaben als ein POST mit JSON oder ein Datei-Upload. Ein konkreter Anwendungsfall ist n8n mit Telegram; dort prüfst du Nachrichteneingang und Antwortaktion getrennt.

Speichere einen geheimen API-Zugang im passenden Credential. Die ergänzende Anleitung erklärt, wie du n8n Credentials dem richtigen Dienst zuordnest. Ein gewöhnliches Headerfeld mit hineinkopiertem Secret erschwert das Teilen und die Kontrolle des Workflows.

Antwortform und HTTP-Status prüfen

Standardmäßig liefert der Node den Antwort-Body. Mit Include Response Headers and Status kommen weitere Informationen dazu. Kontrolliere nach einem Test die tatsächliche Ausgabe; Expressions im Folgeschritt müssen zu dieser Struktur passen.

Für unseren Empfänger ist folgende Antwort vorgesehen:

{
  "accepted": true,
  "item_id": "ART-42"
}

Das ist eine erwartete Beispielantwort, keine aufgezeichnete Messung. Vergleiche beim eigenen Test die Artikelnummer mit den gesendeten Daten. Prüfe außerdem, was accepted in deinem Workflow bedeutet: eine bestätigte Annahme und ein abgeschlossener fachlicher Folgeschritt sind unterschiedliche Befunde.

Die Option Never Error ändert, wie der Node HTTP-Statuscodes behandelt. Wenn du sie bewusst nutzt, brauchst du einen ausdrücklichen Folgecheck für den Status und den Antwortinhalt. Ein technisch weiterlaufender Pfad wird dadurch nicht automatisch zu einer erfolgreichen API-Operation.

Eine Antwort vor dem nächsten Node prüfen

Für den vorhandenen Lager-Testvertrag kannst du die Antwort jetzt ausdrücklich vor der Weiterverarbeitung prüfen. Der Vertrag erwartet eine bestätigte Annahme für ART-42. HTTP-Erfolg und passende Nutzdaten sind getrennte Bedingungen: Eine 200-Antwort mit der falschen Artikelnummer darf den Vertrag nicht erfüllen.

Die Antwortstruktur sichtbar machen

1. Aktiviere im HTTP Request Node unter den Antwortoptionen Include Response Headers and Status. Wähle für dieses Beispiel Response Format: JSON. Kontrolliere in der tatsächlichen Ausgabe statusCode und body.
2. Für bewusst erzeugte HTTP-Fehlerfälle kannst du Never Error im kontrollierten Test verwenden. Dann muss der Folgeschritt den Status ausdrücklich auswerten. Diese Option macht eine abgelehnte Anmeldung nicht erfolgreich und behebt keinen Verbindungsfehler.
3. Füge einen Code-Node mit JavaScript und Run Once for All Items an. Das folgende Beispiel liest die gelieferten Items, verändert keine Stammdaten und ruft keine API auf.

// Code-Node: JavaScript, Run Once for All Items.
// Erwartet Include Response Headers and Status + JSON-Response.
return $input.all().map((item, index) => {
  const response = item.json ?? {};
  const status = response.statusCode;
  const body = response.body;
  const hasStatus = Number.isInteger(status) && status >= 100 && status <= 599;
  const httpOk = hasStatus && status >= 200 && status < 300;
  const bodyOk = body !== null && typeof body === 'object' && !Array.isArray(body)
    && body.accepted === true && body.item_id === 'ART-42';
  const result = !hasStatus ? 'status_fehlt'
    : !httpOk ? 'http_abweichung'
    : !bodyOk ? 'antwort_abweichung'
    : 'vertrag_erfuellt';
  return {
    json: {
      httpStatus: hasStatus ? status : null,
      httpOk,
      antwortPasst: bodyOk,
      pruefstatus: result,
      vertragErfuellt: httpOk && bodyOk,
    },
    pairedItem: { item: index },
  };
});

Zum eigenen Versuch: JavaScript herunterladen · Acht konstruierte Prüffälle.

Die genaue Artikelnummer ist ein bewusst fester Sollwert für diese Übung. Übernimm ART-42 nicht als allgemeine Betriebsregel; in einem echten Workflow vergleichst du die Antwort mit den eindeutig zugeordneten ursprünglichen Eingabedaten. Die Ausgabe erhält über pairedItem die Zuordnung zum jeweiligen Eingabe-Item.

Die acht Downloadfälle wurden als künstliche Eingaben für die reine JavaScript-Funktion entworfen. Sie sind keine aufgezeichneten n8n-Ausführungen. Für deinen Workflow prüfst du zusätzlich den tatsächlichen Anschluss der Nodes und die reale Ausgabeform. Wenn bei einer Verbindungsstörung gar kein Item ankommt, kann dieser Code daraus keinen HTTP-Status erzeugen.

vertragErfuellt bestätigt hier nur die vereinbarten Antwortfelder. Es belegt weder einen abgeschlossenen Lagerprozess noch eine fachliche Freigabe. Insbesondere ist das Skript kein Schutz gegen doppelte Schreibvorgänge nach einem Timeout. Lege dafür die vom Zielsystem unterstützten Wiederholungsregeln separat fest.

Die Antwortoptionen stehen in der bereits verlinkten Node-Referenz. Die Dokumentation zum Code-Node erklärt den verwendeten JavaScript-Modus. Die Benennung von body und statusCode wurde zusätzlich am aktuellen offiziellen HTTP-Request-Quellcode abgeglichen.

cURL-Import und Datentypen kontrollieren

Über Import cURL kann n8n eine vorhandene Anfrage in Node-Einstellungen übertragen. Der Import überschreibt die bisherige Konfiguration. Prüfe daher, welche URL, Header und Werte anschließend im Node stehen, bevor du ihn ausführst.

Die Herstellerreferenz weist darauf hin, dass Parameterwerte beim Import als Strings übernommen werden. Wenn deine API Zahlen oder boolesche Werte benötigt, prüfe den JSON-Modus und den vollständigen Datenkörper. In unserem Beispiel ist 3 eine Zahl; "3" wäre Text. Gleiches gilt für true gegenüber "true".

Ein gültiges JSON-Dokument und ein von der API akzeptierter Datensatz sind zwei Prüfungen. Der Syntaxparser erkennt beispielsweise fehlende Kommas; er weiß nicht, ob der Dienst die Artikelnummer kennt oder das Feld quantity verlangt.

Für Daten aus vorherigen Nodes erklärt der Guide zu n8n Expressions, wie du Datensatz und Ersatzwert richtig auswählst.

Pagination und Requestmenge getrennt planen

Eine API kann eine große Ergebnismenge auf mehrere Seiten verteilen. Die Pagination-Option kann dafür einen Parameter je Request verändern oder einer Next URL aus der Antwort folgen. Prüfe zuerst, welches Verfahren die Ziel-API tatsächlich dokumentiert und wie sie das Ende signalisiert.

Mehrere Eingabe-Items im Workflow sind ein anderer Fall. Mit Batching lässt sich ihre Anfrageverarbeitung gruppieren und verzögern. Ein eigener Prüfvorschlag: Notiere Eingabe-Itemzahl, erwartete Seiten und Abbruchbedingung vor einem größeren Lauf. Eine feste Pause allein beweist nicht, dass alle Regeln des Anbieters eingehalten werden.

Fehler am passenden Schritt eingrenzen

Die Herstellerhilfe zu häufigen Fehlern trennt Verbindungs-, Parameter- und Zugangsprobleme. Unser Diagnoseablauf beginnt beim frühesten gescheiterten Schritt:

In einem n8n-Container bezeichnet localhost den Container selbst. Eine API im Nachbarcontainer benötigt ihre passende Netzwerkadresse; ein lokaler Hostdienst ist ein anderer Zielweg. Ändere erst die Adresse, wenn feststeht, von wo der Node sendet.

Bei einer Schreiboperation solltest du nach einem Timeout vor einem erneuten Versand klären, ob der Dienst den ersten Aufruf bereits verarbeitet hat. Das ist unser Betriebshinweis gegen unbeabsichtigte Doppelaktionen; nicht jede API bietet dafür denselben Wiederholungsschutz.