The HTTP Request Node

What it actually does

The HTTP Request node is n8n’s universal connector. Where most nodes in n8n are built for one specific service — Gmail, Google Sheets, Slack — the HTTP Request node doesn’t care what it’s talking to. If a service has an API and that API speaks HTTP (nearly all of them do), this node can call it: GET to fetch data, POST to create something, PUT or PATCH to update it, DELETE to remove it.

This matters more than it sounds. n8n has hundreds of built-in nodes, but no automation tool covers every service that exists — and even the ones it does cover don’t always expose every feature through their dedicated node. The HTTP Request node is what you reach for the moment you hit that gap. It’s consistently one of the most-used nodes in n8n precisely because of this: it’s the fallback that always works.

Under the hood, you’re configuring four things: the method (GET/POST/etc.), the URL you’re calling, any query parameters or headers the API expects, and — for POST/PUT requests — a body containing the data you’re sending. Whatever the API sends back arrives as JSON, ready for the next node in your workflow to use.

A worked example

The video’s example is about as simple as it gets: a GET request to a free exchange-rate API (api.frankfurter.app), with no authentication required. Set the method to GET, paste in the URL, hit execute — the response lands as structured JSON with current exchange rates, ready to feed into an Edit Fields node or straight into a spreadsheet.

A slightly more realistic example: posting a new lead into a CRM’s API. You’d set the method to POST, add a Content-Type: application/json header, and build a JSON body using data from earlier in your workflow — something like {"name": "{{ $json.name }}", "email": "{{ $json.email }}"}. The API responds with the newly created record, including whatever ID it assigned — which you can then use in later steps, like sending a confirmation email referencing that record.

The mistake almost everyone makes first

A typo in the URL. Get one character wrong in the path and instead of your data, you get an error back: 404 Not Found — the API’s way of saying “the resource you’re requesting could not be found.”

It’s an easy mistake to make, especially when you’re building the URL from a template or copying it from docs — one wrong character in the path and the whole request fails, even though everything else about the setup (method, headers, auth) is correct. The fix is just as easy: check the URL against the API’s own documentation, fix the typo, and re-run.