n8n HTTP Request Node: Calling External APIs from Your Workflows

If there is one node you will use in almost every serious n8n workflow, it is the HTTP Request node.

Most of the services you want to automate — CRMs, databases, analytics platforms, communication tools — expose a REST API. The HTTP Request node is how you talk to them. Understanding it well is the difference between workflows that feel limited and workflows that can reach anything.

What the HTTP Request Node Does

The HTTP Request node sends an HTTP request to a URL and passes the response to the next node in your workflow. That is the whole mechanism. The power comes from how precisely you can control the request — method, headers, body, authentication, query parameters — and how flexibly you can map the response into your data flow.

Basic Configuration

Method — the HTTP verb: GET, POST, PUT, PATCH, DELETE. Most read operations use GET. Most write operations use POST or PUT. PATCH is common for partial updates. DELETE for removing records.

URL — the full endpoint URL. You can include expressions here: https://api.example.com/users/{{ $json.userId }} substitutes a value from the incoming data.

Authentication — how to prove identity to the API. n8n supports:

• None
• Basic Auth (username/password)
• Header Auth (API key in a header like Authorization: Bearer ...)
• OAuth2 (handled via n8n credentials)
• Predefined credentials for specific services (HubSpot, Airtable, etc.)

For most APIs you will use Header Auth with an API key stored in an n8n credential. Never hardcode secrets in the URL or node configuration.

Sending Data

Query Parameters — appended to the URL (?key=value&page=2). Use for filtering, pagination, or simple options. Add them in the “Query Parameters” section of the node rather than manually editing the URL string.

Headers — metadata about the request. Common headers:

• Content-Type: application/json — required when sending a JSON body
• Accept: application/json — tells the server what format you expect back
• X-API-Key: ... — custom API key header format used by some services

Body — the request payload for POST/PUT/PATCH requests. The HTTP Request node supports:

• JSON — most common. Paste a JSON object or build it dynamically using expressions.
• Form Data — for APIs that expect HTML form encoding
• Binary Data — for file uploads
• Raw — for APIs expecting plain text or XML

For JSON bodies, enable “Send Body” and select “JSON” as the body type. You can either write a raw JSON object or use the “Specify Body Using Fields” option to build the object key-by-key with expressions.

Using Expressions in the Request

Expressions let you pull values from incoming workflow data into the request. Inside any field in the HTTP Request node, use {{ }} to write expressions:

• {{ $json.email }} — the email field from the current item
• {{ $json.id }} — use as a path parameter: https://api.example.com/contacts/{{ $json.id }}
• {{ $node["Previous Node"].json.token }} — pull data from a specific earlier node

This is how you build dynamic requests that operate on each item flowing through the workflow.

Handling the Response

By default, n8n automatically parses JSON responses and makes them available as $json in the next node. If the API returns an array of objects, n8n creates one item per object (you can disable this with “Don’t Split Response Items”).

Response Code — available as $response.statusCode. Use an IF node downstream if you need to branch on success vs. error.

Binary Data — if the response is a file (PDF, image, CSV), enable “Response Format: File” to capture it as binary data for downstream processing.

Pagination

Most APIs paginate large result sets. Common patterns:

Offset/Limit pagination: make the first request (?limit=100&offset=0), check if there are more pages (usually a hasMore: true or total > offset + limit in the response), then use a Split in Batches + loop to fetch subsequent pages.

Cursor pagination: the response includes a nextCursor or nextPageUrl. Store the cursor value between requests using a Code node or a database.

n8n does not have native pagination handling — you build the loop manually with Split in Batches or a recursive sub-workflow pattern.

Error Handling

By default, if the API returns a 4xx or 5xx status code, n8n throws an error and stops execution. You have two options:

Continue On Error: enable it on the HTTP Request node. Failed requests pass through with an error object instead of stopping the workflow. Add an IF node downstream to detect $json.error and route errors separately.

Retry On Fail: enable to automatically retry the request 1-5 times with an optional wait between attempts. Useful for transient failures (rate limits, temporary 503s).

For production workflows hitting rate-limited APIs, combine retry with a Wait node between batches. A 429 (Too Many Requests) response usually includes a Retry-After header — you can read this value and feed it into the Wait node duration.

Common Integration Patterns

Lookup and enrich: receive an item with an email address, call a CRM API to look up the contact, merge the response data with the original item using a Merge node.

Conditional write: check if a record exists (GET), then branch with an IF node — create it (POST) if not found, update it (PATCH) if it already exists.

Bulk read with pagination: fetch all records from a large dataset across multiple pages, aggregate with a Code node, then process the full set.

Webhook receiver to API caller: receive incoming data on a Webhook node, transform it with a Set node, and forward it to another API — effectively acting as a middleware layer.

Debugging Tips

Enable “Include Response Headers” to see the full headers returned by the API. This is useful when debugging rate limit state (X-RateLimit-Remaining) or tracing request IDs.

Use the n8n execution log to inspect exactly what was sent and received. The “Input” and “Output” panels on each node show the full data before and after, including the raw response body before JSON parsing.

When an API call fails with an unclear error, switch to “Raw” response format to see the exact response body — sometimes the error message is buried inside an HTML error page or a non-standard JSON structure.

The HTTP Request node has no opinion about what you connect to. Any service with an HTTP API is reachable — and that is most of the internet.