n8n and External APIs: Working with the HTTP Node

The HTTP node is the core tool in n8n. Ready integrations cover the popular services; everything else goes through this node, and that is what separates n8n from builders where “no such integration” ends the conversation.

The HTTP node, step by step

An order that saves time:

1. Test the request outside n8n. Build it in curl or an API client and confirm it works. Then an error inside n8n is definitely configuration rather than the API.
2. Method and URL. Obvious, yet a common mistake is GET instead of POST because the documentation example was for a different endpoint.
3. Headers. Content type matters: many APIs silently return an error on the wrong header.
4. Request body. This is where things break most often when the body is assembled from a previous node: confirm the expressions were substituted rather than sent as literal text.
5. Authentication through credentials, see below.

A useful habit: one item first, then the whole flow. The node runs per incoming item, and a misconfiguration across fifty items means fifty failed requests and a possible rate-limit block.

Authentication

Three options, and all three belong in credentials rather than the request body.

A key in a header or query parameter. The most common case. Set it up as a generic credential so the value stays out of workflow exports.

Basic authentication. Username and password. Same principle.

OAuth. Harder to configure, but n8n refreshes the token for you. The callback URL matters here: on a self-hosted install it must be publicly reachable and match what the provider has on file.

Why credentials rather than variables: workflow exports and execution history are visible to anyone with interface access. A key typed into a request body ends up in both.

Pagination

External APIs rarely return everything at once. The usual mechanisms are a page number, an offset, or a cursor returned in the response.

The HTTP node has a built-in pagination mode where you configure the advance mechanism and the stop condition. Two rules:

A stop condition is mandatory. Without one the workflow loops until it hits an API limit or a timeout. This is the leading cause of “the workflow is hanging”.

Cap the page count. Even with a correct condition, set an upper bound: a changed response format should not become an infinite loop.

Separately: do not pull everything in one run when the data is large. Fetching tens of thousands of records at once means an execution measured in tens of minutes and an enormous history entry. Fetch in batches on a schedule, tracking the last processed record.

Errors and rate limits

External APIs fail, respond slowly and throttle. What to do:

Distinguish error types. An authorisation error is not fixed by retrying, so retrying is pointless. Network errors and rate limits are exactly what retries are for.

Retries with increasing delay. The node has built-in retries; if the API returns a retry-after header, honour it rather than guessing an interval.

Limit concurrency. n8n runs the node per item, and a hundred items means a hundred requests back to back. Many APIs will not tolerate that: batch them and add a pause.

Timeouts. A request without one can hang an execution for a long time.

Decide what happens to a failed item. Skip and continue, or stop the whole workflow. The default is to fail everything, which is not always right. The mechanics are in error handling.

Debugging

The execution history is the main tool: you see what entered the node and what it returned. When an external API misbehaves, read the actual response rather than assuming: the error body almost always explains the cause better than the status code.

How to parse the response and reach nested fields is covered in data and expressions and JSON in n8n. The overview is in the n8n guide.