Authorization header not working on n8n Cloud - 401 error but works fine from curl

Questions
1

Describe the problem/error/question

The HTTP Request node sends a 401 Unauthorized to the Infobip WhatsApp API, despite the Authorization header being configured correctly. The same request works perfectly via curl from the terminal with the identical API key, headers, and body.

The execution log shows “authorization”: “hidden” — the header value appears to be blanked or corrupted before being sent to the API.

I’ve tried: Header Auth credential, Custom Auth credential with JSON, manual header with Auth set to None, expression mode for header value — all return 401. curl with the same key from the same machine returns 200 every time.

This appears to be the same __n8n_BLANK_VALUE credential reset bug reported in GitHub issues #12596, #14615, #17655.

What is the error message (if any)?

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

Please share your workflow

new users can’t upload attachments:(

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 that authorization: hidden in the log doesnt prove the value got blanked — n8n hides header values in the execution view, so it could just be redaction. only way to know what actually goes out is echo it: point the http request at a webhook.site url and read the authorization header it receives. blank or __n8n_BLANK_VALUE = yeah its the bug you found. full correct value = its not n8n dropping it, check the App prefix infobips key needs is intact.

3

that was a good idea, checked what’s coming to the webhook, all is fine on n8n side. It’s probably some kind of Infobips internal security policy, because I tested from outside our network and it failed. Thanks for the help:)

4

@Danijel_Domjanovic yeah thats an ip allowlist on infobips side then. n8n cloud goes out on rotating datacenter ips so you cant just whitelist it. easiest fix is route the call through a static-ip proxy you control (a small vps) and allowlist that one ip in infobip.

5

Welcome @Danijel_Domjanovic!

The IP allowlist is one possible cause, but the “hidden” value in the execution log is worth investigating separately - it points to a credential blank-value issue, not just IP filtering. Quick way to rule it out: switch the HTTP Request node to use a hardcoded Authorization header (set Auth to None, add the header manually in the Headers tab with the token typed inline, not from a credential). If that returns 200, the credential itself is the problem, not the IP. You can then re-create the credential from scratch rather than editing the existing one, since the __n8n_BLANK_VALUE bug often survives edits but not recreation.