Solicitud HTTP devuelve 401 "No valid key" mientras que la misma solicitud funciona en Postman

Preguntas
1

Describir el problema/error/pregunta

Hola a todos,
Estoy enfrentando un problema extraño con la solicitud HTTP de n8n.
Entorno
n8n Auto-alojado 2.20.11
Nodo HTTP Request v4.4
API externa utilizando autenticación JWT Bearer
Qué sucede
Llamo al endpoint de Autorización de la API desde n8n.
La API devuelve un token JWT válido.
Uso ese token exacto en un segundo nodo HTTP Request.
La API responde con:
{
“result”: “error”,
“description”: “No valid key”
}
Estado HTTP: 401
Importante
El mismo token copiado manualmente desde n8n en Postman funciona correctamente.
El proveedor de la API ha verificado el endpoint y las credenciales.
El cURL exacto exportado desde Postman fue importado en un nodo HTTP Request completamente nuevo y sigue fallando en n8n.
Opción de Headers en minúsculas probada.
Configuración de Gzip / compresión probada.
Accept-Encoding: identity probado.
El encabezado de Autorización se envía como:
Authorization: Bearer
El proveedor de la API probó la misma solicitud desde Postman con el mismo token y recibe:
{
“result”: “ok”,
“idlead”: “5”
}
¿Ha visto alguien un caso donde n8n envía algo diferente a Postman incluso al importar el cURL exacto?
¿Alguna idea sobre cómo inspeccionar la solicitud saliente sin procesar desde n8n?
Gracias.

¿Cuál es el mensaje de error (si hay alguno)?

Comparte tu flujo de trabajo

Comparte el resultado devuelto por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (predeterminada: SQLite):
  • Configuración n8n EXECUTIONS_PROCESS (predeterminada: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:
2

@Hector_AnVa la forma más rápida de ver exactamente qué envía n8n (precisamente lo que pediste): apunta ambas a un inspector de solicitudes. obtén una URL de webhook.site, configura el nodo de n8n Y tu solicitud de Postman para que la utilicen, ejecuta ambas, compara los encabezados capturados. eso siempre expone la diferencia.

ya has descartado mayúsculas/gzip, así que los dos culpables habituales:

  • Authorization duplicada. si la autenticación del nodo está configurada en una credencial Y también hay un encabezado Authorization manual (la importación de cURL a menudo agrega uno), n8n envía dos y la api devuelve 401, mantén exactamente uno.
  • encabezados predeterminados de n8n, agrega un User-Agent y a veces Accept-Encoding que Postman no tiene, y las puertas de enlace estrictas lo rechazan por eso.

puesto que incluso el cURL importado falla, mis apuestas están en la Authorization duplicada, la comparación de webhook.site lo confirma en 30 segundos.

3

Para ver exactamente qué está enviando n8n, usa un servicio de inspección de solicitudes. Esta es la forma más confiable de comparar la solicitud de n8n con la solicitud de Postman.

  • Usa Webhook.site:
    1. Ve a Webhook.site y copia la URL única proporcionada.
    2. Cambia la URL de tu segundo nodo HTTP Request a esta URL de Webhook.site.
    3. Ejecuta el nodo.
    4. Inspecciona los encabezados y el cuerpo en la interfaz de Webhook.site.

Qué buscar: Verifica si Authorization está siendo codificado dos veces, si hay espacios en blanco adicionales, o si Content-Type es diferente de lo que tu API espera.

El “Authentication: Predefined Credential Type” de n8n a veces puede agregar encabezados que entren en conflicto con tu encabezado Authorization agregado manualmente. Asegúrate de no estar enviando accidentalmente dos encabezados Authorization.

  • Prueba: Establece el desplegable de Authentication en “None” y usa estrictamente un parámetro de Header llamado Authorization con el valor Bearer <TOKEN>.

Si estás pasando el token a través de una expresión (p. ej., {{ $json.token }}), asegúrate de que no haya saltos de línea finales o espacios ocultos siendo capturados del nodo anterior. Intenta recortarlo: {{ $json.token.trim() }}.

Algunas APIs bloquean solicitudes basándose en el encabezado predeterminado User-Agent de axios (a menudo axios/x.x.x). Intenta agregar un encabezado User-Agent personalizado (p. ej., Mozilla/5.0...) para simular un navegador.

Asegúrate de que el encabezado Accept esté explícitamente configurado (p. ej., application/json), ya que algunas APIs se comportan de manera diferente si se envía el */* predeterminado.

4

Complementando el consejo de @kjooleng sobre Webhook.site: Una causa muy frecuente de exactamente este patrón (el token funciona en Postman, el mismo token falla en n8n) es un espacio invisible o un salto de línea al final del token, que se inserta al copiar desde la primera respuesta HTTP a n8n.

Puntualmente a verificar: En el primer nodo HTTP Request que devuelve el JWT, observa el output detenidamente, preferiblemente a través del Code Node con JSON.stringify($json.token) en lugar de la vista normal. Si aparece "\n" u espacios adicionales al final, esa es la causa. Postman frecuentemente recorta automáticamente al pegar manualmente, n8n no lo hace.

La solución sería entonces aplicar un .trim() al campo del token antes de pasarlo al segundo request, ya sea a través de un Code Node o directamente en el Expression field: {{ $json.token.trim() }}.

5

@Hector_AnVa puedes probar Webhook.site, apunta n8n y Postman a la misma URL y compara qué se está enviando realmente.

Causa más probable: encabezado Authorization duplicado. Al importar cURL, a veces n8n añade el suyo encima.

Solución: establece Authentication en «None» y usa solo un encabezado Authorization: Bearer manual.

También verifica:

Limpia tu token: {{ $json.token.trim() }} los espacios ocultos rompen la autenticación

Añade un User-Agent personalizado — el predeterminado de n8n (axios/x.x.x) es rechazado por algunas APIs