Authorization header no funciona en n8n Cloud - error 401 pero funciona bien desde curl

Preguntas
1

Describe the problem/error/question

El nodo HTTP Request envía un 401 Unauthorized a la API de Infobip WhatsApp, a pesar de que el encabezado Authorization está configurado correctamente. La misma solicitud funciona perfectamente a través de curl desde la terminal con la misma clave API, encabezados y cuerpo.

El registro de ejecución muestra “authorization”: “hidden” — el valor del encabezado parece estar en blanco o corrompido antes de enviarse a la API.

He intentado: Header Auth credential, Custom Auth credential con JSON, encabezado manual con Auth establecido en None, modo expresión para el valor del encabezado — todos retornan 401. curl con la misma clave desde la misma máquina retorna 200 cada vez.

Esto parece ser el mismo bug de reinicio de credencial __n8n_BLANK_VALUE reportado en los problemas de GitHub #12596, #14615, #17655.

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

401 - "{"requestError":{"serviceException":{"messageId":"UNAUTHORIZED","text":"Invalid login details"}}}"

Please share your workflow

los usuarios nuevos no pueden cargar archivos adjuntos:(

Share the output returned by the last node

{
"headers": {
"authorization": "hidden",
"content-type": "application/json",
"accept": "application/json,text/html,application/xhtml+xml,application/xml,text/;q=0.9, image/;q=0.8, /;q=0.7"
},
"method": "POST",
"uri": "``https://3v16p1.api.infobip.com/whatsapp/1/message/text``",
"json": false
}

Information on your n8n setup

  • n8n version: 2.28.4
  • Database (default: SQLite): default
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): n8n cloud
  • Operating system: cloud
2

@Danijel_Domjanovic eso de authorization: hidden en el log no prueba que el valor se haya eliminado — n8n oculta los valores de encabezados en la vista de ejecución, así que podría ser solo redacción. la única manera de saber qué se envía realmente es verificarlo: apunta la solicitud http a una url de webhook.site y lee el encabezado de authorization que recibe. blank o __n8n_BLANK_VALUE = sí, es el bug que encontraste. valor completo correcto = no es n8n eliminándolo, verifica que la clave de infobips del prefijo App esté intacta.

3

fue una buena idea, revisé qué llega al webhook, todo está bien del lado de n8n. Probablemente sea algún tipo de política de seguridad interna de Infobips, porque lo probé desde fuera de nuestra red y falló. ¡Gracias por la ayuda! :slight_smile:

4

@Danijel_Domjanovic sí, entonces es una lista de IP permitidas del lado de Infobip. n8n cloud sale desde IPs de centros de datos rotativas, así que no puedes simplemente agregarlas a la lista blanca. La solución más fácil es enrutar la llamada a través de un proxy de IP estática que controles (una pequeña VPS) y agregar esa única IP a la lista blanca en Infobip.

5

¡Bienvenido @Danijel_Domjanovic!

La lista blanca de IP es una posible causa, pero el valor “hidden” en el registro de ejecución merece investigarse por separado - apunta a un problema de credencial con valor en blanco, no solo a filtrado de IP. Una forma rápida de descartarlo: cambia el nodo HTTP Request para usar un encabezado Authorization codificado (establece Auth en None, añade el encabezado manualmente en la pestaña Headers con el token escrito directamente, no desde una credencial). Si eso devuelve 200, el problema está en la credencial misma, no en la IP. Luego puedes recrear la credencial desde cero en lugar de editar la existente, ya que el error __n8n_BLANK_VALUE a menudo sobrevive las ediciones pero no la recreación.