Hallo zusammen,
Ich habe ein seltsames Problem mit der n8n HTTP Request.
Umgebung
n8n Self Hosted 2.20.11
HTTP Request node v4.4
Externe API mit JWT Bearer-Authentifizierung
Was passiert
Ich rufe den API Authorization Endpoint von n8n auf.
Die API gibt ein gültiges JWT Token zurück.
Ich verwende dieses Token in einem zweiten HTTP Request node.
Die API antwortet mit:
{
“result”: “error”,
“description”: “No valid key”
}
HTTP Status: 401
Wichtig
Das gleiche Token, das manuell von n8n in Postman kopiert wird, funktioniert korrekt.
Der API-Anbieter hat den Endpoint und die Anmeldedaten überprüft.
Das von Postman exportierte exakte cURL wurde in einen brandneuen HTTP Request node importiert und schlägt in n8n immer noch fehl.
Lowercase Headers Option getestet.
Gzip-/Komprimierungseinstellungen getestet.
Accept-Encoding: identity getestet.
Authorization Header wird gesendet als:
Authorization: Bearer
Der API-Anbieter hat die gleiche Anfrage von Postman mit dem gleichen Token getestet und erhält:
{
“result”: “ok”,
“idlead”: “5”
}
Hat jemand einen Fall gesehen, in dem n8n etwas anders sendet als Postman, selbst wenn das exakte cURL importiert wird?
Habt ihr Ideen, wie man die rohe ausgehende Anfrage von n8n inspizieren könnte?
Danke.
Welche Fehlermeldung wird angezeigt (falls vorhanden)?
@Hector_AnVa schnellster Weg zu sehen, was n8n tatsächlich sendet (genau das, was du gefragt hast): Beide auf einen Request Inspector zeigen. Schnapp dir eine webhook.site-URL, stell den n8n-Node UND deine Postman-Anfrage so ein, dass sie beide darauf zielen, feuere beide ab, diff die erfassten Header. Das macht den Unterschied immer sichtbar.
du hast Groß-/Kleinschreibung/gzip ausgeschlossen, also die zwei üblichen Verdächtigen:
doppeltes Authorization. Wenn die Authentication des Nodes auf eine Credential gesetzt ist UND es auch einen manuellen Authorization-Header gibt (der cURL-Import fügt oft einen hinzu), sendet n8n zwei und die API antwortet mit 401, halte genau einen.
n8ns Standard-Header, es fügt einen User-Agent und manchmal Accept-Encoding hinzu, das Postman nicht hat, und strenge Gateways lehnen das ab.
da auch die importierte cURL fehlschlägt, mein Geld liegt auf dem doppelten Authorization, der webhook.site-Diff bestätigt es in 30 Sekunden.
Um genau zu sehen, was n8n sendet, verwenden Sie einen Request-Inspektionsdienst. Dies ist die zuverlässigste Methode, um die n8n-Anfrage mit der Postman-Anfrage zu vergleichen.
Gehen Sie zu Webhook.site und kopieren Sie die bereitgestellte eindeutige URL.
Ändern Sie die URL Ihres zweiten HTTP-Request-Knotens auf diese Webhook.site-URL.
Führen Sie den Knoten aus.
Inspizieren Sie die Header und den Body in der Webhook.site-Oberfläche.
Was Sie überprüfen sollten: Prüfen Sie, ob Authorization doppelt codiert wird, ob zusätzliche Leerzeichen vorhanden sind, oder ob der Content-Type anders ist als das, was Ihre API erwartet.
Ergänzend zu @kjooleng’s Webhook.site-Tipp: Eine sehr häufige Ursache für genau dieses Muster (Token funktioniert in Postman, identisches Token schlägt in n8n fehl) ist ein unsichtbares Leerzeichen oder ein Zeilenumbruch am Ende des Tokens, das beim Kopieren aus der ersten HTTP-Response in n8n eingefügt wird.
Konkret zu prüfen: Im ersten HTTP Request Node, der das JWT zurückgibt, schau dir den Output genau an, am besten über den Code-Node mit JSON.stringify($json.token) statt der normalen Ansicht. Wenn dort "\n" oder zusätzliche Leerzeichen am Ende auftauchen, ist das die Ursache. Postman trimmt häufig automatisch beim manuellen Einfügen, n8n tut das nicht.
Fix wäre dann ein .trim() auf das Token-Feld vor der Übergabe an den zweiten Request, entweder über einen Code-Node oder direkt im Expression-Feld: {{ $json.token.trim() }}.