The HTTP Request node: reach every API without an official integration

Why you need this node

At the source snapshot, n8n listed 400+ integrations, covering many well-known SaaS products; check the live catalog because the count changes. But pull the camera back — the world holds a few hundred thousand services with an API:

• Internal systems your company self-hosts (ticketing, inventory and ordering, CRM) — n8n was never going to build those
• Regional SaaS (a local accounting product, logistics service, or invoicing API) — sometimes too niche for an official node
• Services that just launched — n8n has not had time to build a node yet
• Things everyone uses that n8n happens not to cover (some obscure CI/CD tool, say)
• Services you wrote yourself, and your department's internal microservices

As long as it has a REST API (the kind where you call a URL and JSON comes back), you can reach it with the HTTP Request node. This node holds the same place as the Code node: it is n8n's escape hatch, and anything the ready-made nodes cannot do, you can put together here.

The chapter in one line: when you find that n8n has no node for a service, do not panic — read their API docs, open an HTTP Request node, fill in four fields, and you are through. Note: the English edition uses globally applicable regional-service examples; verify the API, authentication, and legal requirements for your own market.

The four parts of an HTTP call

Whichever API you are calling, one HTTP call always means deciding four things. Skip this if you already know HTTP; if you do not, three minutes here pays off for good —

Method is really just a verb: it says what you want to do to that URL —

• GET: fetch — read a piece of data without changing anything (example: pull the customer list)
• POST: create — add a new record (example: create a new user)
• PUT: replace the whole record — overwrite the existing one with the body you send
• PATCH: partial update — change a few fields and keep the rest
• DELETE: delete — the record is gone (example: delete that user)

Headers carry information along with the call. The two you meet most:

• Authorization: Bearer <your-token> — proves who you are
• Content-Type: application/json — tells the other side "I am sending JSON"

Body is only filled in for POST, PUT and PATCH — it is the data you are sending over, usually a lump of JSON. GET and DELETE carry no body (a few APIs are exceptions, but not many).

Three things to look for in API docs

When you open the docs for an API you have never used — Stripe, Notion, or your company's internal system — there are three things to find. Everything else is trimming:

1. Endpoint URL (where to send it)

   A sidebar or a table in the docs usually lists every address you can call, for example https://api.example.com/v1/users, https://api.example.com/v1/orders/{id}. Braces like {id} in an address mean you replace that part with a real value.

2. Method (which verb to use)

   Every endpoint is labeled GET, POST, PUT or DELETE — that is the method the endpoint takes. The same URL sometimes supports several methods (GET /users returns the list, POST /users creates a new one), so read carefully and do not mix them up.

3. Auth (how you authenticate)

   There is always an Authentication section near the front telling you which scheme they use. Three are common: a Bearer token in a header (most modern APIs), ?api_key=xxx on the end of the URL (the older style), and a full OAuth round trip (Google, Facebook and the like). Work out which one it is and you know what to fill in.

Docs look different from vendor to vendor, but those three are always written down somewhere. If you cannot find them, the docs are bad, or you need to go ask their support.

Hands-on: call your first API (public GitHub data)

Start with a public API that needs no auth, just to get used to the node. The goal: fetch the public data for the GitHub user octocat (their octopus-cat mascot).

1. Add an HTTP Request node to the canvas

   Press + on an empty part of the canvas to open the nodes panel, search for http and pick HTTP Request. It lands on your workflow with connector dots on both sides (the same as an Action node). If there is no Trigger node in front of it, add a Manual Trigger (so you can run it by hand) and wire the two together.

2. Set Method to GET

   Open the node's panel on the right and set the Method dropdown at the top to GET (GET is the default, so usually there is nothing to change).

3. Put https://api.github.com/users/octocat in URL

   Paste that address into the URL field below. It is GitHub's own public REST API for reading one user's data.

4. Leave Authentication on None

   Public data needs no auth. In real work you will usually pick Generic Credential Type or Predefined Credential Type; both come later in this chapter, so skip them on your first run.

5. Press Execute step

   The Execute step button sits at the top right of the node (some versions call it Test step). Press it and n8n really does call the API.

6. Read the JSON in the output pane on the right

   Within seconds the octocat's data appears on the right — login: "octocat", id: 583231, name: "The Octocat", avatar_url: "...", public_repos: 8 — one whole block of JSON. That means your API call worked.

7. The next node can read fields with {{ $json.login }}

   Wire a Slack or Set node after this HTTP Request and type User {{ $json.login }} has {{ $json.public_repos }} repos into the message field; at run time it is replaced with the real values. That is an expression, and Chapter 14 is devoted to it.

Three common ways to authenticate

Public APIs are the minority; in practice most of them want auth. Here are the styles you will run into:

The Authentication dropdown inside the node has a few options:

• None — public APIs need no auth
• Predefined Credential Type — n8n has these set up for you, so just pick the matching service (OpenAI, Notion or HubSpot, for example)
• Generic Credential Type — you name the scheme yourself, and the dropdown offers seven: Basic Auth, Custom Auth, Digest Auth, Header Auth, OAuth1 API, OAuth2 API, Query Auth (some versions also have Simplified Custom Auth)

Hands-on: POST JSON to an API

GET fetches, POST sends. In practice you reach for POST whenever you want n8n to create a record in another SaaS. Say a messaging API's endpoint is POST /messages and the body has to be {"text": "message body", "to": "[email protected]"} — here are the steps:

1. Change Method to POST

   Set the Method dropdown at the top of the right-hand panel to POST. Once POST is selected, a Send Body option appears below it.

2. Put the endpoint in URL

   For example https://api.example.com/v1/messages. Their docs always give you this.

3. Set up Authentication

   Pick whatever they require — usually Generic Credential Type → Header Auth, holding one Authorization: Bearer <your-token> pair.

4. Turn on Send Body

   If you are sending a body, switch Send Body on.

5. Set Body Content Type to JSON

   A Body Content Type menu appears, and n8n offers five options: JSON, Form URLencoded, Form-Data, n8n Binary File, Raw. Most modern APIs take JSON; a file-upload form takes Form-Data; raw binary (a PDF sent straight through, say) takes n8n Binary File; XML or a custom MIME type takes Raw. Pick whatever their docs say.

6. Set Specify Body to Using JSON and paste the payload

   A large text box appears. Paste this in:

   {
     "text": "{{ $json.message }}",
     "to": "[email protected]"
   }

   The {{ $json.message }} in there is an expression; it reads the message field from the previous node. Hard-coding is fine too — just type "hello".

7. Execute step and read the response

   Press run. Their API's response appears in the output pane on the right — usually a confirmation like {"id": "msg_xxx", "status": "sent"}. If {"error": "..."} comes back instead, see the troubleshoot section.

Common API patterns at a glance

Almost every REST API looks alike — the four CRUD operations (Create, Read, Update, Delete) map onto four methods. Recognize the pattern and their docs go much faster:

Query parameters (the ?a=1&b=2 part after the question mark) do not have to be typed by hand in the HTTP Request node. Switch on Send Query Parameters and fill in one Name/Value pair per row. n8n assembles the correct URL for you, URL encoding included (Chinese characters and spaces are escaped automatically).

Handling pagination

Most APIs will not return everything at once — they cap one response at 100 records (some at 50, some at 25). To pull 500 customers you have to call five times in a row, one page each. That is pagination.

The good news: the n8n HTTP Request node has pagination built in, so you do not write the loop yourself. The steps:

1. Open the node's Pagination tab

   Scroll down the node's right-hand panel to the Pagination block and change Pagination Mode from Off to the mode you want.

2. Pick the mode — follow their API docs

   Two are common:

   • Response Contains Next URL — the JSON the API returns holds a next or next_url field, and n8n follows it automatically
   • Update a Parameter in Each Request — you tell n8n which query parameter to change each time (page=1, 2, 3... or cursor=xxx, for example)

3. Set Complete Expression (when to stop)

   n8n decides whether to stop with a boolean expression — the field is called Complete Expression. Fill in something like {{ $response.body.results.length === 0 }} (stop when an empty array comes back) or {{ !$response.body.next_page }} (stop when there is no next page). You can also set Limit Pages Fetched as a safety cap on the number of pages (20 at most, say).

4. Run it and look at the output

   n8n makes the calls back to back and merges every page into one output. The next node sees the full 500 records and never has to care about pagination.

The official pagination docs are thorough, with an example for every pattern: docs.n8n.io/code/cookbook/http-node/pagination.

Create a credential for the HTTP Request node

If you keep using the same API key against several endpoints at the same SaaS (GET the customer list, POST a message to each customer, DELETE the expired ones), do not paste the token into every node. Store the token as a credential and share it across nodes instead.

1. Left sidebar Credentials → Create Credential

   Pick Credentials in the main sidebar on the left, then press Create Credential at the top right (or the guided button you get the first time).

2. Search for Header Auth

   Search the credential type list for header and pick Header Auth (older interfaces show it as HTTP Header Auth — same thing). It is the most general one: Bearer tokens and X-API-Key both go through it.

3. Put Authorization in Name and Bearer <your-token> in Value

   Name is the header field's name, Value is its value. Save the pair and give the credential a name you will recognize, such as MyCompany CRM Bearer.

4. Back in the node, set Authentication to Generic Credential Type → Header Auth → the credential you just made

   From then on every request this node makes carries that header automatically. Point several nodes at the same credential and changing the token is a one-place edit.

The node's other common options, in one pass

An Add Option button at the bottom of the node opens more advanced settings. You will meet these sooner or later:

Common errors and fixes

When a call does not get through, the error message is usually an HTTP status code. Knowing a handful of them saves a lot of time:

1. 401 Unauthorized (no auth, or the wrong token)

   Auth is set up wrong, or the token expired. Get one successful call through Postman, Insomnia or curl first, then come back and compare — copy the curl that works, and fill the node's Method, URL and Header to match it field by field. That isolates the problem (an n8n setting, or the token/URL).

2. 403 Forbidden (signed in, but not allowed)

   The token is right, but you have no permission for this endpoint. Read the scope or role section of their API docs — a specific permission usually has to be granted (OpenAI wants a read or write scope, Slack wants chat:write). Issue a new token with the right permissions.

3. 404 Not Found (wrong URL, or the record does not exist)

   A typo in the URL, a missing /v1/, or a wrong {id} in the path (that record does not exist). Compare it against the URL in the docs carefully; building a URL with an expression makes an extra or missing slash especially easy.

4. 429 Too Many Requests (you are calling too fast)

   Their API has a rate limit (60 calls a minute, say) and you went over it. Three fixes: (1) set an interval in the node's Options → Batching; (2) put a Wait node in front to slow it down; (3) turn on Retry on Fail with Retry Wait on the node (Chapter 17 covers it in detail).

5. 500 / 502 / 503 (their server fell over)

   Not your problem — their API is down. Turning on Retry on Fail (three retries, five seconds apart) usually gets you through. A 500 that keeps coming means they really are broken; search twitter for their status page.

6. 200, but HTML comes back instead of JSON

   Your URL is wrong — a 302 has probably redirected you to a sign-in page or an error page. Check whether the output is a pile of <html> and <body> tags. Compare the URL carefully, confirm auth is set up, and confirm the API base URL is right. Sometimes https vs http is enough to trigger the redirect.

7. It succeeds, but the body is empty

   Check whether the status code is 204 No Content — that means "it worked, there is nothing to return", which is normal. DELETE often returns 204. Or the API is simply designed that way (no body on success). To tell whether it worked, switch on Options → Response → Full Response and judge by the status code.

8. SSL certificate errors

   Internal company APIs often use a self-signed SSL certificate. Turning on Options → Add Option → Ignore SSL Issues (Insecure) in the node skips verification. Do this for internal services only — never switch off SSL verification against a public API, because it opens you to a man-in-the-middle attack.

FAQ