HTTP Request retourne 401 "No valid key" alors que la même requête fonctionne dans Postman

Questions
1

Décrivez le problème/l’erreur/la question

Bonjour à tous,
Je rencontre un problème étrange avec HTTP Request de n8n.
Environnement
n8n Self Hosted 2.20.11
Nœud HTTP Request v4.4
API externe utilisant l’authentification JWT Bearer
Ce qui se passe
J’appelle le point de terminaison Authorization de l’API depuis n8n.
L’API retourne un jeton JWT valide.
J’utilise exactement ce jeton dans un second nœud HTTP Request.
L’API répond avec :
{
“result”: “error”,
“description”: “No valid key”
}
Statut HTTP : 401
Important
Le même jeton copié manuellement de n8n dans Postman fonctionne correctement.
Le fournisseur d’API a vérifié le point de terminaison et les identifiants.
Le cURL exact exporté de Postman a été importé dans un nouveau nœud HTTP Request et échoue toujours dans n8n.
Option Lowercase Headers testée.
Paramètres Gzip / compression testés.
Accept-Encoding: identity testé.
L’en-tête Authorization est envoyé comme :
Authorization: Bearer
Le fournisseur d’API a testé la même requête depuis Postman avec le même jeton et reçoit :
{
“result”: “ok”,
“idlead”: “5”
}
Quelqu’un a-t-il rencontré un cas où n8n envoie quelque chose de différent de Postman, même lors de l’importation du cURL exact ?
Avez-vous des idées sur la façon d’inspecter la requête sortante brute de n8n ?
Merci.

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre flux de travail

Partagez la sortie retournée par le dernier nœud

Informations sur votre configuration n8n

  • Version de n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

@Hector_AnVa le plus rapide pour voir ce que n8n envoie réellement (exactement ce que tu demandais) : pointe les deux vers un inspecteur de requêtes. récupère une URL webhook.site, configure le nœud n8n ET ta requête Postman pour la cibler, déclenche les deux, fais un diff des en-têtes capturés. ça expose toujours la différence.

tu as écarté la casse/gzip, donc les deux suspects habituels :

  • Authorization en double. si l’authentification du nœud est définie sur une credential ET qu’il y a aussi un en-tête Authorization manuel (l’import cURL en ajoute souvent un), n8n en envoie deux et l’API retourne 401, garde exactement un.
  • les en-têtes par défaut de n8n, il ajoute un User-Agent et parfois un Accept-Encoding que Postman n’a pas, et les passerelles strictes rejettent sur ceux-ci.

puisque même le cURL importé échoue, je parie sur le double Authorization, le diff webhook.site le confirme en 30 secondes.

3

Pour voir exactement ce que n8n envoie, utilisez un service d’inspection de requêtes. C’est le moyen le plus fiable de comparer la requête n8n avec la requête Postman.

  • Utilisez Webhook.site :
    1. Allez sur Webhook.site et copiez l’URL unique fournie.
    2. Changez l’URL de votre deuxième nœud HTTP Request vers cette URL Webhook.site.
    3. Exécutez le nœud.
    4. Inspectez les en-têtes et le corps dans l’interface Webhook.site.

À vérifier : Vérifiez si Authorization est doublé au codage, s’il y a des espaces superflus, ou si Content-Type est différent de ce que votre API attend.

Le « Authentication: Predefined Credential Type » de n8n peut parfois ajouter des en-têtes qui entrent en conflit avec votre en-tête Authorization ajouté manuellement. Assurez-vous que vous n’envoyez pas accidentellement deux en-têtes Authorization.

  • Test : Réglez la liste déroulante Authentication sur « None » et utilisez strictement un paramètre Header nommé Authorization avec la valeur Bearer <TOKEN>.

Si vous transmettez le jeton via une expression (par exemple, {{ $json.token }}), assurez-vous qu’aucune nouvelle ligne ni espace caché ne soit capturé depuis le nœud précédent. Essayez de le découper : {{ $json.token.trim() }}.

Certaines API bloquent les requêtes en fonction de l’en-tête User-Agent axios par défaut (souvent axios/x.x.x). Essayez d’ajouter un en-tête User-Agent personnalisé (par exemple, Mozilla/5.0...) pour imiter un navigateur.

Assurez-vous que l’en-tête Accept est explicitement défini (par exemple, application/json), car certaines API se comportent différemment si la valeur par défaut */* est envoyée.

4

En complément du conseil de @kjooleng sur Webhook.site : Une cause très fréquente de ce schéma exact (le token fonctionne dans Postman, le même token échoue dans n8n) est un espace invisible ou un saut de ligne à la fin du token, qui s’insère lors de la copie de la première réponse HTTP dans n8n.

Concrètement à vérifier : Dans le premier nœud HTTP Request qui retourne le JWT, examine attentivement la sortie, de préférence via le nœud Code avec JSON.stringify($json.token) au lieu de la vue normale. Si des "\n" ou des espaces supplémentaires apparaissent à la fin, c’est la cause. Postman supprime souvent automatiquement lors de l’insertion manuelle, n8n ne le fait pas.

La solution serait alors d’appliquer un .trim() au champ token avant de le passer à la deuxième requête, soit via un nœud Code, soit directement dans le champ Expression : {{ $json.token.trim() }}.

5

@Hector_AnVa tu peux essayer Webhook.site, pointer n8n et Postman vers la même URL et comparer ce qui est réellement envoyé.

Cause la plus probable : en-tête Authorization en doublon. Lors de l’import de cURL, n8n ajoute parfois le sien par-dessus.

Fix : définis Authentication sur « None » et utilise seulement un en-tête Authorization: Bearer manuel.

Vérifie aussi :

Trim ton token : {{ $json.token.trim() }} les espaces cachés cassent l’authentification

Ajoute un User-Agent personnalisé le défaut de n8n (axios/x.x.x) est rejeté par certaines APIs