Node-RED http request: node headers overwrite msg.headers (Sume key)

The answer

Node-RED's help for the http request node says that any headers set in the node configuration overwrite matching headers in msg.headers. So put the Sume credential in the node's own header list, where it cannot be replaced by an upstream message, and put per-request headers such as Idempotency-Key in msg.headers.

Sume wants exactly one credential. Its OpenAPI says to send either Authorization: Bearer sume_live_... or x-api-key: sume_live_..., and that a request carrying both is rejected with 401 unauthorized (Send only one API key credential.). Pick one and leave the other out everywhere.

Which header lives where

Splitting the headers this way keeps the secret in one place and the intent-specific value with the message that needs it.

The collision to avoid

Because the node configuration wins, a message that carries its own authorization key is silently replaced for that header. That is the safe direction for a credential, but it means you cannot override the key per message, for example to use a second workspace. For that case use a second node with its own configured header.

The opposite mistake is the 401 case. If a flow template already sets x-api-key in msg.headers and the node adds Authorization, the call fails with the single-credential error. Search your flows for both before you rotate a key.

A short function node

The function below sets only the message-level headers. The node's configured Authorization header is not repeated here.

msg.headers = {
  "content-type": "application/json",
  "idempotency-key": "invoice-" + msg.invoiceId + "-r1",
};
msg.url = "https://api.sume.com/v1/images";
msg.method = "POST";
msg.payload = { model: "sume/auto", mode: "async", prompt: msg.prompt };
return msg;

Rotating the key

Because the credential lives in one node, rotating a Sume key is a one-place change: create the new key in the dashboard, paste it into the node's header, deploy, then revoke the old one. Sume API responses never return the full secret key, so the dashboard is the only place you see it at creation time; store it straight into the node.

If you run several environments, keep one configured node per environment rather than one node with message-level overrides, which the precedence rule would ignore.

Testing the header split

Check the split with a harmless read before trusting it with a paid submit. Point a request node at https://api.sume.com/v1/me with only the Authorization header configured in the node, and feed it a message that also sets an authorization header with a wrong value in msg.headers. Per the node help, the configured header overwrites the matching message header, so the call should succeed and msg.statusCode should be 200.

Then flip the test: remove the node-level header and keep the message-level one. If the call now works with a valid key in the message, you have confirmed the second half of the rule, that message headers are used when the node does not configure the same header. Delete the test message afterwards so the key is not left in a flow.

Finally send both authorization and x-api-key once on purpose and confirm the 401 single-credential response. Seeing that error in a controlled test makes it much easier to recognise in a real flow.