n8n HTTP Request Node

The HTTP Request node is the most powerful tool in n8n. While n8n offers 400+ pre-built integrations, the HTTP Request node lets you connect to any API—even ones without dedicated nodes.

Need to pull data from an internal company API? Send webhooks to a custom service? Integrate with a niche tool that doesn’t have an n8n node? The HTTP Request node handles it all, no coding required.

This guide covers everything you need to master API calls in n8n: authentication, headers, pagination, error handling, and real-world examples you can adapt to your workflows.

When to Use the HTTP Request Node

Before diving into how, let’s clarify when:

Scenario	Use HTTP Request?
Service has a dedicated n8n node	No—use the built-in node for easier setup
Service has no n8n node	Yes—HTTP Request is your only option
Built-in node missing a feature you need	Yes—HTTP Request gives full API access
Calling internal/private APIs	Yes—no built-in nodes for custom APIs
Webhooks to custom endpoints	Yes—perfect for sending data anywhere

Rule of thumb: Start with built-in nodes when available. Switch to HTTP Request when you need more control or when no node exists.

Understanding API Requests

Every HTTP request has four key components:

1. URL: Where the request goes (e.g., https://api.example.com/users)
2. Method: What action to perform (GET, POST, PUT, DELETE)
3. Headers: Metadata about the request (authentication, content type)
4. Body: Data you’re sending (for POST/PUT requests)

Think of it like sending a letter:

• URL = the address
• Method = “please read this” vs. “please update my account”
• Headers = the envelope information
• Body = the letter contents

Your First HTTP Request

Let’s start with something simple: fetching data from a public API.

Step 1: Add the HTTP Request Node

1. Open your n8n workflow
2. Click + to add a node
3. Search for “HTTP Request”
4. Click to add it

Step 2: Configure a GET Request

We’ll fetch a random user from the free JSONPlaceholder API:

1. Method: GET (this is the default)
2. URL: https://jsonplaceholder.typicode.com/users/1
3. Leave everything else as default
4. Click Test step

Step 3: Read the Response

You’ll see a JSON response like:

{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "[email protected]",
  "address": {
    "street": "Kulas Light",
    "city": "Gwenborough"
  }
}

You can now use this data in subsequent nodes with expressions like:

• {{ $json.name }} → “Leanne Graham”
• {{ $json.email }} → “[email protected]”
• {{ $json.address.city }} → “Gwenborough”

Common Beginner Mistakes

Mistake 1: Forgetting the protocol

❌ api.example.com/users
✅ https://api.example.com/users

Mistake 2: Wrong method for the operation

❌ Using GET when the API expects POST
✅ Check the API documentation for the correct method

Mistake 3: Not testing before connecting other nodes

❌ Building a full workflow, then discovering the API call fails
✅ Always click "Test step" on the HTTP Request node first

HTTP Methods Explained

Different HTTP methods tell the API what action you want to perform:

GET: Retrieve Data

Use GET to fetch information without changing anything.

GET https://api.example.com/users
GET https://api.example.com/orders/123
GET https://api.example.com/products?category=electronics

Key points:

• No request body needed
• Parameters go in the URL (query strings)
• Safe to repeat—doesn’t change data

POST: Create or Send Data

Use POST to create new records or send data to be processed.

POST https://api.example.com/users
Body: { "name": "John", "email": "[email protected]" }

Key points:

• Requires a request body
• Creates new resources
• Not idempotent—repeating may create duplicates

PUT/PATCH: Update Data

Use PUT to replace a resource entirely, PATCH to update specific fields.

PUT https://api.example.com/users/123
Body: { "name": "John Updated", "email": "[email protected]" }

PATCH https://api.example.com/users/123
Body: { "email": "[email protected]" }

Key points:

• PUT replaces the entire resource
• PATCH updates only specified fields
• Both require a request body

DELETE: Remove Data

Use DELETE to remove resources.

DELETE https://api.example.com/users/123

Key points:

• Usually no request body needed
• Irreversible—be careful with automation
• Some APIs use POST with a delete action instead

Quick Reference Table

Method	Purpose	Has Body?	Idempotent?
GET	Retrieve data	No	Yes
POST	Create/send data	Yes	No
PUT	Replace resource	Yes	Yes
PATCH	Partial update	Yes	Yes
DELETE	Remove resource	Rarely	Yes

Authentication: Connecting to Protected APIs

Most APIs require authentication to prove who you are. The HTTP Request node supports multiple authentication methods.

No Authentication

Some APIs are public and require no authentication:

1. Leave Authentication set to “None”
2. Enter the URL and send your request

Examples: Public weather APIs, JSONPlaceholder, some government data APIs.

API Key Authentication

The most common method for simple APIs. The API key can be sent in different places:

Option 1: API Key in Header

1. Set Authentication to “Generic Credential Type”
2. Select “Header Auth”
3. Create credentials with:
   • Name: The header name (e.g., X-API-Key, Authorization)
   • Value: Your API key

Or manually add the header:

1. Expand Options → Headers
2. Add your header:

   Name: X-API-Key
   Value: your-api-key-here

Option 2: API Key in Query String

Some APIs want the key in the URL:

https://api.example.com/data?api_key=your-api-key-here

In n8n:

1. Expand Options → Query Parameters
2. Add:

   Name: api_key
   Value: your-api-key-here

Bearer Token Authentication

Common for OAuth 2.0 and JWT-based APIs:

1. Set Authentication to “Generic Credential Type”
2. Select “Header Auth”
3. Create credentials:
   • Name: Authorization
   • Value: Bearer your-token-here

Or predefined:

1. Set Authentication to “Predefined Credential Type”
2. Select “Header Auth”
3. Configure with your token

Basic Authentication

For APIs using username/password:

1. Set Authentication to “Generic Credential Type”
2. Select “Basic Auth”
3. Enter your username and password

n8n automatically encodes these as a Base64 header.

OAuth 2.0

For services requiring OAuth flows (Google, Microsoft, Salesforce):

1. Set Authentication to “Predefined Credential Type”
2. Search for and select the OAuth2 credential type
3. Follow the OAuth flow to authorize

For detailed troubleshooting, see our guide to fixing n8n authentication errors.

Authentication Comparison

Method	Security	Complexity	Best For
None	Low	Easy	Public APIs
API Key	Medium	Easy	Most third-party APIs
Bearer Token	High	Medium	Modern REST APIs
Basic Auth	Medium	Easy	Legacy systems
OAuth 2.0	High	Complex	User-context APIs

Headers: The Hidden Power

Headers carry metadata about your request. While n8n sets many automatically, some APIs require custom headers.

Content-Type Header

Tells the API what format your request body is in:

Content-Type	When to Use
application/json	JSON data (most common)
application/x-www-form-urlencoded	Form data
multipart/form-data	File uploads
text/plain	Plain text

n8n sets Content-Type: application/json automatically when you use JSON body. Override it in Options → Headers if needed.

Common Custom Headers

Accept: application/json          // What format you want back
X-Request-ID: unique-id-123       // For request tracking
User-Agent: MyApp/1.0             // Identify your application
Cache-Control: no-cache           // Bypass caching

Dynamic Headers with Expressions

Use expressions to set headers dynamically:

// Header value from previous node
{
  {
    $("Previous Node").item.json.apiKey;
  }
}

// Current timestamp
{
  {
    Date.now();
  }
}

// Computed signature
{
  {
    $json.computedSignature;
  }
}

This is useful when APIs require signed requests or dynamic tokens. If you’re building complex expressions, our expression validator tool can help catch errors before runtime.

Request Body: Sending Data

For POST, PUT, and PATCH requests, you need to send data in the body.

JSON Body (Most Common)

1. Set Body Content Type to “JSON”
2. Add your JSON:

{
  "name": "New Customer",
  "email": "[email protected]",
  "plan": "premium"
}

Using Expressions in JSON

Make your request body dynamic using data from previous nodes:

{
  "name": "{{ $json.customerName }}",
  "email": "{{ $json.customerEmail }}",
  "orderId": "{{ $('Order Node').item.json.id }}",
  "timestamp": "{{ $now.toISO() }}"
}

Form Data

For APIs expecting form submissions:

1. Set Body Content Type to “Form Urlencoded”
2. Add key-value pairs in the form fields

Common JSON Errors

Error: “JSON parameter need to be an valid JSON”

This happens when expressions break JSON syntax. Wrap the entire object in expression brackets:

{{
  {
    "name": $json.name,
    "items": $json.items
  }
}}

If you’re struggling with malformed JSON, try our JSON fixer tool to identify and correct formatting issues.

Error: Values not substituting

Make sure expressions are inside the JSON, not outside:

❌ {{ { "name": "John" } }}
✅ { "name": "{{ $json.firstName }}" }

Handling API Responses

Once your request succeeds, you need to work with the response data.

Accessing Response Data

The response becomes available as $json in subsequent nodes:

// Access top-level properties
{
  {
    $json.id;
  }
}
{
  {
    $json.status;
  }
}

// Access nested properties
{
  {
    $json.data.user.name;
  }
}
{
  {
    $json.results[0].title;
  }
}

// Access array items
{
  {
    $json.items[0];
  }
}
{
  {
    $json.items.length;
  }
}

Handling Different Response Formats

JSON Response (Default)

Most APIs return JSON. n8n parses it automatically:

{
  {
    $json.propertyName;
  }
}

Array Response

If the API returns an array, each item becomes a separate n8n item:

[
  { "id": 1, "name": "Item 1" },
  { "id": 2, "name": "Item 2" }
]

Both items flow through your workflow separately.

Binary Response (Files)

For file downloads, enable “Response Format” → “File” in options. The file becomes available as binary data for use with file nodes.

Checking Response Status

To access the HTTP status code, enable Options → Full Response:

{
  {
    $json.statusCode;
  }
} // 200, 404, 500, etc.
{
  {
    $json.headers;
  }
} // Response headers
{
  {
    $json.body;
  }
} // The actual response data

Pagination: Getting All Your Data

Many APIs limit how much data they return per request. Pagination lets you fetch all results across multiple requests.

Why APIs Paginate

Returning 10,000 records at once would be slow and memory-intensive. Instead, APIs return pages of results (e.g., 100 at a time) with information about how to get the next page.

n8n’s Built-in Pagination

The HTTP Request node has automatic pagination support:

1. Expand Options → Pagination
2. Choose your pagination type

Offset-Based Pagination

APIs that use offset and limit parameters:

Page 1: /api/items?offset=0&limit=100
Page 2: /api/items?offset=100&limit=100
Page 3: /api/items?offset=200&limit=100

Configure in n8n:

• Pagination Mode: Offset
• Limit Parameter: limit
• Offset Parameter: offset
• Page Size: 100

Cursor-Based Pagination

APIs that return a nextCursor or next_page token:

{
  "data": [...],
  "nextCursor": "abc123xyz"
}

Configure in n8n:

• Pagination Mode: Cursor
• Next URL: {{ $response.body.nextCursor }} or the next page URL

Page Number Pagination

APIs that use page numbers:

Page 1: /api/items?page=1
Page 2: /api/items?page=2

Configure using expressions:

• Next Page URL Expression: Include {{ $pageCount + 1 }} in your URL

Pagination Best Practices

1. Set a maximum: Configure “Max Pages” to prevent infinite loops
2. Add delays: Some APIs require delays between requests (see our rate limiting guide)
3. Monitor performance: Paginating through thousands of items takes time

Error Handling and Retry

API calls can fail for many reasons. n8n provides tools to handle errors gracefully.

Common HTTP Error Codes

Code	Meaning	Typical Cause
400	Bad Request	Malformed request or invalid data
401	Unauthorized	Invalid or expired credentials
403	Forbidden	Valid credentials, insufficient permissions
404	Not Found	Resource doesn’t exist
429	Too Many Requests	Rate limit exceeded
500	Server Error	API-side problem
503	Service Unavailable	API temporarily down

Retry on Failure

Enable automatic retries for transient failures:

1. Expand Options → Retry on Fail
2. Set Max Tries: How many times to retry (e.g., 3)
3. Set Wait Between Tries: Delay in milliseconds (e.g., 1000)

This handles temporary network issues and brief API outages automatically.

Continue on Fail

If you want the workflow to continue even when the HTTP Request fails:

1. Open node Settings (gear icon)
2. Enable Continue On Fail

The node outputs an error object instead of stopping the workflow:

{
  {
    $json.error;
  }
} // Error message
{
  {
    $json.statusCode;
  }
} // HTTP status code

Error Trigger Workflow

For complex error handling, use the Error Trigger node:

1. Create a separate workflow with Error Trigger
2. Configure it to run when your main workflow fails
3. Send notifications, log errors, or trigger recovery actions

For timeout-related errors, check our timeout troubleshooting guide.

Real-World Examples

Example 1: Fetching Data from a REST API

Scenario: Get all products from your e-commerce API

Method: GET
URL: https://api.mystore.com/products
Authentication: Header Auth (X-API-Key)

Response handling:

// Filter to in-stock items in next node
{
  {
    $json.items.filter((item) => item.inStock);
  }
}

Example 2: Posting Data to a Webhook

Scenario: Send form submission to a custom endpoint

Method: POST
URL: https://hooks.mycompany.com/form-handler
Content-Type: application/json
Body:
{
  "formId": "{{ $json.formId }}",
  "submittedAt": "{{ $now.toISO() }}",
  "data": {
    "name": "{{ $json.name }}",
    "email": "{{ $json.email }}",
    "message": "{{ $json.message }}"
  }
}

Example 3: Authenticated API with Pagination

Scenario: Sync all contacts from a CRM

Method: GET
URL: https://api.crm.com/v1/contacts
Authentication: Bearer Token
Pagination:
  - Mode: Cursor
  - Next URL: {{ $response.body.pagination.next }}
  - Complete When: {{ !$response.body.pagination.hasMore }}

Example 4: Downloading a File

Scenario: Download a report PDF

Method: GET
URL: https://api.reports.com/export/monthly.pdf
Authentication: API Key
Options:
  - Response Format: File
  - Put Output in Field: data

The PDF becomes available as binary data for use with Google Drive, S3, or email nodes.

Pro Tips and Best Practices

1. Test Before Building

Always click “Test step” on your HTTP Request node before connecting other nodes. This verifies:

• The URL is correct
• Authentication works
• The response format matches expectations

Use our workflow debugger to catch issues across your entire workflow.

2. Use Variables for URLs

Don’t hardcode URLs. Store base URLs in credentials or use expressions:

// If you have the base URL from a previous node or variable
{{ $vars.apiBaseUrl }}/users/{{ $json.userId }}

This makes switching between staging and production easier.

3. Keep Credentials Secure

Never put API keys directly in the URL or body. Use n8n credentials:

❌ https://api.example.com/data?key=sk_live_1234567890
✅ Use Header Auth credential with your API key

See our self-hosting mistakes guide for more security best practices.

4. Handle Empty Responses

Some APIs return empty responses (204 No Content). Handle these gracefully:

{
  {
    $json.data ? $json.data : [];
  }
}

5. Log Important Requests

For debugging and auditing, log critical API calls:

1. Add a Set node after HTTP Request
2. Include request details, response status, and timestamp
3. Send to a logging service or database

6. Respect Rate Limits

Many APIs limit requests per minute/hour. Read the rate limiting guide to:

• Understand limit headers
• Implement throttling
• Handle 429 errors gracefully

When to Get Help

The HTTP Request node handles most API integration needs. But some scenarios benefit from expert help:

• Complex OAuth flows with multiple authorization steps
• SOAP/XML APIs with strict schema requirements
• GraphQL APIs needing optimized queries
• Webhooks requiring cryptographic signature verification

Our workflow development services and consulting packages can accelerate complex integrations.

For best practices on structuring workflows, see our n8n workflow best practices guide.

Frequently Asked Questions

When should I use HTTP Request instead of a built-in node?

Use the HTTP Request node when: (1) no dedicated node exists for your service, (2) the built-in node doesn’t support the specific endpoint or feature you need, (3) you’re connecting to internal/private APIs, or (4) you need more control over headers, authentication, or request formatting than the built-in node provides. Start with built-in nodes when available—they handle authentication and pagination automatically—and switch to HTTP Request only when you hit limitations.

How do I debug failed HTTP requests in n8n?

Start by clicking “Test step” on the HTTP Request node to see the exact error. Enable Options → Full Response to see the status code, headers, and raw response body. Common debugging steps: (1) verify the URL is correct and includes https://, (2) check authentication credentials are valid and not expired, (3) test the same request in Postman or curl to isolate whether the issue is n8n-specific, (4) check the API documentation for required headers or parameters you might be missing. For persistent issues, try our workflow debugger tool.

Can I download files using the HTTP Request node?

Yes. Set Options → Response Format to “File” and the binary data will be available for use with file-handling nodes (Google Drive, S3, FTP, Email attachments). You can also specify which field the binary data should be stored in using “Put Output in Field”. For large files, consider increasing the node timeout in Settings → Timeout to prevent timeouts during download.

How do I handle APIs that require multiple authentication steps?

Some APIs require a preliminary request to obtain an access token before making the actual API call. Build this as a two-step process: (1) First HTTP Request node gets the token from the auth endpoint, (2) Second HTTP Request node uses that token in the Authorization header. For OAuth 2.0 flows with refresh tokens, n8n’s built-in OAuth2 credential type handles token refresh automatically. For truly complex auth (like AWS Signature V4), you may need a Function node to compute the signature before the HTTP Request.

Why does my API request work in Postman but not in n8n?

The most common causes are: (1) Header differences—Postman may be sending headers you’re not replicating in n8n, like Accept or User-Agent. Enable “Full Response” and compare headers. (2) Body formatting—Postman automatically formats JSON while n8n expressions might break JSON syntax. Validate your JSON structure. (3) Authentication timing—OAuth tokens might expire between getting them and using them. (4) URL encoding—special characters in URLs might be encoded differently. Try URL-encoding parameters manually if needed. (5) SSL issues—if you’re hitting internal APIs with self-signed certificates, you may need to disable SSL verification in node options (not recommended for production).