HTTP Request node broken after Cloud update 2.19.5 - config.headers.setContentType is not a function

Questions
,
1

HTTP Request node broken after update to n8n Cloud 2.19.5 (config.headers.setContentType is not a function)

After upgrading to n8n Cloud 2.19.5, HTTP Request nodes started failing with:

config.headers.setContentType is not a function

Environment:

  • n8n Cloud

  • version: 2.19.5

Affected node:

  • HTTP Request

  • node version: 4.2

Minimal reproduction:

  • Method: GET

  • URL:

https://api.openai.com/v1/vector_stores

Authentication:

  • Predefined Credential Type

  • Credential Type: OpenAI

The request fails before reaching the endpoint.

I also tested:

  • Authentication = None

  • manual Authorization header

  • removing Content-Type

  • Using JSON

  • Using Fields Below

  • creating a brand new HTTP Request node

Same error in all cases.

Example stack trace:

NodeApiError: config.headers.setContentType is not a function

This started immediately after the cloud upgrade.

Is anyone else seeing this on Cloud 2.19.5?

3

it’s likely a broken Axios/header handling issue introduced in the latest cloud update, i could be wrong

4

@Gianluca Welcome to the community!

Yes, this looks like a Cloud 2.19.5 regression, not your HTTP config.

Since it fails even with:

  • new HTTP Request node

  • auth disabled

  • manual headers

  • simple GET request

…it likely happens before the request is sent.

Best workaround for now:

  • report it to n8n support with this minimal reproduction

  • ask if they can roll back or patch your Cloud instance

  • avoid upgrading other instances to 2.19.5 if possible

5

Hi,

I tried creating new HTTP Request node but nothing …

image
image1875×865 71.3 KB

6

@Gianluca looked at the github issue more carefully — bug is in n8n’s global axios request interceptor for any URL starting with https://api.openai.com/. applyVendorHeaders reassigns config.headers to a plain object that doesn’t have setContentType, so the interceptor crashes downstream. Affects every code path that goes through n8n’s request helper (HTTP Request node, Code node, AI Agent node) regardless of credential type.

n8n team has it tracked as issue #29471, marked “in-linear, team-assigned” so a fix is coming. While you wait:

  • the langchain OpenAI node (@n8n/n8n-nodes-langchain.openAi) uses a different SDK path and may sidestep the interceptor — worth trying for the operations it covers
  • if you need the raw vector_stores endpoint, route through a tiny proxy (Cloudflare Worker or any URL that forwards to api.openai.com) so the URL doesn’t trigger the interceptor
7

unfortunately does’nt work

image
image1659×657 69 KB

8

confirmed bug — n8ns global axios interceptor blows up on any URL starting with api.openai.com/. applyVendorHeaders rewrites config.headers to a plain object, then a downstream interceptor cant call setContentType on it and dies. affects HTTP Request, Code (helpers.httpRequest), AI Agent — everything that goes through n8ns request helper, cred type doesnt matter since the match is URL-based.

tracked here:

cleanest unblock until n8n patches it is a cloudflare worker proxy. ~5 min setup, free tier handles 100k req/day.

at workers.cloudflare.com → create worker → paste:

export default {
async fetch(request) {
const url = new URL(request.url);
url.host = ‘api.openai.com’;
url.protocol = ‘https:’;
return fetch(new Request(url, request));
}
}

10

You have to look at the terms and conditions carefully. Real life usage is only good for around 15 minutes.

image
image822×676 10.8 KB

11

@kjooleng yeah I see what you’re highlighting, that 10ms CPU is a real limit, that sucks