n8n MCP custom headers with OAuth token refresh: Sume caution

n8n 2.40 (2026-09-15) made MCP registry remotes support custom headers that survive OAuth token refreshes. If you point one at Sume, pick a single credential: OAuth or an API key, not both. Sume's API rejects a request that carries both Authorization: Bearer and x-api-key with 401 unauthorized, so an x-api-key header that persists next to an OAuth bearer token is a setup to avoid.

What did n8n 2.40 change?

The n8n release notes for 2.40, dated 2026-09-15, say MCP registry remotes support custom headers that survive OAuth token refreshes. The same entry lists other changes to the AI Agent and HTTP Request nodes.

Why does a persistent header matter with Sume?

Sume's authentication page says a request carrying both Authorization: Bearer and x-api-key is rejected with 401 unauthorized and the message Send only one API key credential. Neither header wins. The page describes this for API keys on the Developer API; the MCP OAuth page says the two credentials are not interchangeable, so mixing an OAuth token with an API-key header is a setup to avoid.

How do I set up the API-key case?

The OAuth page says API-key remote MCP sends either Authorization: Bearer $SUME_API_KEY or x-api-key: $SUME_API_KEY. Choose one, and do not also configure OAuth on the same server entry. Create keys in the dashboard and rotate them if they show up in logs.

Where does this fit with n8n's other Sume posts?

For the node itself, see n8n MCP client tool with Sume. The endpoint to use is https://mcp.sume.com/mcp, and the authentication docs have the header rule in full.

How do I keep the setup clean?

Decide per server entry. If it is an OAuth connection, let n8n manage the token and add only headers that have nothing to do with authentication. If it is an API-key connection, put the key in exactly one header and leave OAuth off.

The docs also warn that gateways and fetch wrappers that add their own Authorization header on top of a client that already sends x-api-key cause the rejection. A header that survives token refreshes is the same trap in a new place, so check the resulting request rather than the form fields.

What does a failure look like?

The response is a 401 unauthorized with the message Send only one API key credential. If you see that after adding a custom header in n8n, look for an x-api-key or Authorization header that duplicates the credential the connection already sends.

Remove the extra header and retry. The error is a header conflict rather than a bad key, so rotating the key will not help, though the docs do say to rotate keys that have appeared in logs.