How to Connect n8n to Any API (No Code Required)

What the HTTP Request node does

The HTTP Request node is a universal API client built into n8n. You give it a URL, a method (GET, POST, PUT, PATCH, DELETE), authentication credentials, and optional headers or a request body — and it calls the API and outputs the response as JSON that every downstream node can use.

Use it when: the API you need doesn't have a native n8n node, the native node is missing a specific endpoint, you're calling an internal microservice, or you need to call a webhook on another system. In practice, the HTTP Request node handles roughly 30–40% of all API calls in real production workflows — native nodes cover the common operations, but edge cases and custom endpoints always end up here.

One thing it does that most people miss: you can chain multiple HTTP Request nodes in a single workflow and pass data between them. The output of the first API call (say, a customer ID from a lookup) goes directly into the URL or body of the second call. No intermediate storage, no code needed.

The fastest way: cURL import

Every API documentation page has cURL examples — the one-line shell commands showing exactly how to call each endpoint. n8n has an "Import cURL" button in the HTTP Request node that reads a cURL command and fills in the URL, method, headers, and body automatically. This cuts configuration time from 5 minutes to 30 seconds.

Take this example from OpenAI's documentation:

curl https://api.openai.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Copy that, open an HTTP Request node, click Import cURL (the small link at the top of the node panel), paste it, and n8n fills: Method = POST, URL = https://api.openai.com/v1/chat/completions, Headers = Content-Type and Authorization, Body = the JSON payload. You then replace the hardcoded API key value with a credential reference — and the node is ready.

Reading API documentation → translating to n8n fields

The skill that makes API integration fast isn't knowing n8n deeply — it's knowing how to read an API reference and map it to the right node fields. Most API docs follow the same structure. Here's the translation:

Path parameters like {customer_id} in the URL go directly into the URL field as n8n expressions: https://api.example.com/v1/customers/{{ $json.customer_id }}. The value gets substituted at runtime from whatever the previous node returned. This is how you chain API calls — first call gets the ID, second call uses it.

Authentication types — which to use

In the HTTP Request node, open the Authentication section and select the credential type. n8n stores credentials separately from workflows, so your API keys never appear in the node configuration — they're injected at runtime.

5 real API integrations with full node configs

Handling pagination — all 3 modes

Most APIs don't return all results in one response — they paginate. Without pagination configured in n8n, you get the first page only (typically 10–100 records). The HTTP Request node has built-in pagination under Options → Pagination that handles this automatically, merging all pages into a single output array. No looping, no extra nodes.

Working with the response — extracting nested data

The HTTP Request node outputs the full API response as $json. When the API returns a flat object, the fields are immediately accessible: {{ $json.id }}, {{ $json.email }}. When the API wraps the data in a container — which is most of the time — you need to go deeper.

OpenAI returns { "choices": [{ "message": { "content": "..." } }] } — the text you want is at {{ $json.choices[0].message.content }}. Stripe returns customer data nested inside a data array when listing. GitHub wraps repository data in an array at the top level. The pattern for all of these: add a Set node immediately after the HTTP Request node and map the nested fields to clean, flat field names that the rest of your workflow can use without repeated deep-path expressions.

When the response is an array (GitHub repo list, Airtable records), n8n automatically splits it into individual items — each array element becomes a separate item in the workflow output. You don't need to loop manually. If the array is nested inside a wrapper (e.g. { "records": [...] }), open the HTTP Request node's Options section and set Output Format → Items from Array with the field path set to records. n8n will unpack the nested array into individual items automatically.

Error handling and rate limits

By default, any non-2xx HTTP response (400, 401, 403, 404, 429, 500) causes the HTTP Request node to throw an error and stop the workflow. For workflows that run on incoming data — where one bad record shouldn't kill the whole run — this is the wrong behavior. Fix it with two settings in the node options.

First: in the HTTP Request node, under the three-dot menu → Settings, enable Continue on Fail. When this is on, error responses pass through as data instead of stopping the workflow. The response will include a statusCode field. An IF node after the HTTP Request can check {{ $json.statusCode }} and route errors to a separate branch — log them to a Google Sheet, send a Slack alert, or skip the item entirely.

Second: enable Retry on Fail in the same Settings menu. Set Max Tries to 3 and Wait Between Tries to 2000ms (2 seconds). This handles transient errors — a momentary API timeout or a 500 from an overloaded server — without any manual intervention. For rate limit errors (429), the standard retry delay of 2 seconds is often not enough. Most APIs that return 429 include a Retry-After header telling you how long to wait. Add a Wait node (set to 60 seconds) on the 429 branch before looping back to retry.

Frequently Asked Questions

Related Articles