Error - HTTP PUT Request - Cannot read properties of undefined


I am getting error with using HTTP Request node (PUT)

The good thing is that the request works fine, the PUT it happened and updates the data on the server.

But why this error shows up?

ERROR: Cannot read properties of undefined (reading 'includes')
TypeError: Cannot read properties of undefined (reading 'includes')
    at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/V3/HttpRequestV3.node.js:1067:41)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/src/Workflow.js:645:28)
    at async /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/src/WorkflowExecute.js:562:53


Sorry to hear that you have problems. Can you please share a workflow that shows the problem so that we are able to debug it. Thanks!

Thanks for the quick response.

Here is the workflow I used.

Trying to use to azure with api bearer auth which works fine again.

and then it makes a call as per # Public IP Addresses - List All - REST API (Azure Virtual Networks) | Microsoft Learn and then the errors happens in the last node when sends the ip addresses to via PUT

When sharing workflows it is always important that they are runnable. Meaning that somebody else can simply copy and paste them and then see the problem. I tried to do that with the workflow you shared by removing a node, hardcoding the value and making a request The workflow I ended up with was this, which however executes totally fine for me:

Can you please make the adjustments to see the problem you face.

I’m getting the same error communicating with supabase (the request is actually transferred succesfully to supabase). Not sure how to share it since it contains credentials, but here’s a screenshot of a single node that fails with this error:

The error:

TypeError: Cannot read properties of undefined (reading 'includes')
    at Object.execute (/app/code/node_modules/n8n-nodes-base/dist/nodes/HttpRequest/V3/HttpRequestV3.node.js:1067:41)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Workflow.runNode (/app/code/node_modules/n8n-workflow/dist/src/Workflow.js:645:28)
    at async /app/code/node_modules/n8n-core/dist/src/WorkflowExecute.js:562:53

Version: 0.198.2

That is very helpful to know that actually the request goes through but the response is what is causing the problem. Looks like the response from the API does potentially not contain the header content-type which causes problems.

Until we have a chance to look into that properly in a few days and fix, you can maybe try with the older version of the node. For that, copy the workflow-code below into your workflow. You should then receive the older version of the node. Configure it accordingly and see if it works.

I can confirm that it works with the older version of the HTTP node.

Great, thanks a lot!

Hi @jan the workflow is runnable, is just I removed the subid from the URL since it’s my Azure instance and the cred + the server destination.

Thanks for looking into it.

To confirm in my case, the request is passing successfully as well, it’s just the n8n shows that UI error.

@systemaddict which n8n version that is working with you and not throwing an error?

@ansred with runnable I meant that it can be executed by anybody by clicking “execute” without having to make changes or sign up and configure an external service like Azure, in this case. That is not always possible but the closer we get to it and the more information that gets included, the easier it is for us.

Version: 0.198.2

If you copy/paste the HTTP node from the inserted workflow above, you get the old version of the HTTP node and that doesn’t throw this error.

We rely on the response content-type to guess how to parse the response. I’m your case, the response did not include a content-type. I just added a condition to avoid erroring in this case. However, because of this, the response might not be parsed correctly, so make sure you set the response format explicitly in options → response format.


@RicardoE105 You are right, once I did add the options content type json; the workflow worked just fine as expected with no errors.

Thanks for sharing the github ticket as well.

Great we could figure it out. It will be available in the next release. Thanks for reporting the issue.

1 Like

Got released with [email protected]

1 Like