The HTTP Request node is the backbone of n8n. It appears in 73% of all production workflows, and for good reason: it connects n8n to any system that exposes an API, which in 2026 means virtually every business tool, database, and service you use. Whether you are pulling data from a CRM, posting messages to Slack, syncing records between two systems, or calling a machine learning model, the HTTP Request node is how n8n talks to the outside world.

This documentation covers every option, parameter, and configuration pattern available in the n8n HTTP Request node as of version 1.x. It is structured as both a reference guide and a practical tutorial, with working examples for the most common API integration patterns.

What the HTTP Request Node Does

The HTTP Request node sends HTTP requests to any URL and processes the response. It supports all standard HTTP methods (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), all authentication types (API key, OAuth 2.0, Bearer token, Basic Auth, custom headers), and handles JSON, XML, form data, multipart uploads, and binary file responses.

In practical terms, this means you do not need to wait for n8n to build a dedicated node for every service. When a native node exists (like the Slack node or HubSpot node), it provides a more guided experience with pre-built operations. But the HTTP Request node can do everything a native node does, plus interact with services that have no native n8n node at all.

Core Configuration: Method and URL

Every HTTP Request starts with two fundamental choices: the HTTP method and the URL.

HTTP Methods Explained

• **GET** — Retrieve data. Used for fetching records, lists, search results, or any read-only operation. Example: get all contacts from a CRM, fetch the current weather, retrieve an invoice PDF
• **POST** — Create new data. Used for creating records, submitting forms, sending messages, or triggering actions. Example: create a new lead in HubSpot, send a Slack message, upload a file
• **PUT** — Replace existing data entirely. Used when you want to overwrite a complete record with new data. Example: update a full contact profile, replace a document
• **PATCH** — Partially update existing data. Used when you want to change specific fields without affecting others. Example: update just the email field on a contact, change a task status
• **DELETE** — Remove data. Used for deleting records, cancelling subscriptions, or removing resources. Example: delete a test contact, remove a file from storage
• **HEAD** — Same as GET but returns only headers, no body. Used to check if a resource exists or get metadata without downloading the full response
• **OPTIONS** — Returns the HTTP methods and options supported by a URL. Rarely used directly in workflows

URL Configuration

The URL field accepts both static URLs and dynamic expressions. In most production workflows, the URL contains expressions that reference data from previous nodes:

Static: `https://api.hubspot.com/crm/v3/contacts`

Dynamic: `https://api.hubspot.com/crm/v3/contacts/{{$json.contactId}}`

The double-brace expression syntax `{{}}` lets you insert values from previous nodes, environment variables, or workflow variables into any part of the URL. This is essential for operations like updating a specific record where the ID comes from an earlier node in the workflow.

Always use expressions for IDs and parameters rather than hardcoding values. A workflow that fetches contact ID 12345 is a test. A workflow that fetches `{{$json.contactId}}` is production-ready.

Authentication Methods

The HTTP Request node supports five authentication methods, covering every API authentication pattern you will encounter.

No Authentication

Some APIs require no authentication for public endpoints. Weather APIs, public data APIs, and webhook receivers often accept unauthenticated requests. Select "None" in the authentication dropdown.

API Key Authentication

The most common pattern for simple API integrations. The API key is sent either as a query parameter or as a header.

**As a header** (most common): The key is sent in a custom header, typically `X-API-Key`, `Authorization`, or a service-specific header name. In n8n, create a credential of type "Header Auth" with the header name and value.

**As a query parameter**: The key is appended to the URL as a parameter. Less secure (keys appear in server logs) but still used by some APIs. In n8n, create a credential of type "Query Auth" with the parameter name and value.

Bearer Token / OAuth 2.0

For services that use OAuth 2.0 (Google, Microsoft, Salesforce, HubSpot, and most enterprise APIs), select the "OAuth2" authentication type. n8n handles the full OAuth flow: initial authorization, token storage, and automatic token refresh when the access token expires.

Configuration requires: Authorization URL, Access Token URL, Client ID, Client Secret, and Scope. These values come from the API provider's developer documentation. Once configured, n8n prompts you to authorize the connection through the service's login page, then stores and manages the tokens automatically.

Basic Authentication

Username and password sent as a Base64-encoded header. Used by older APIs and some internal services. In n8n, create a "Basic Auth" credential with username and password fields.

Custom Authentication

For APIs with non-standard authentication (HMAC signatures, custom token schemes, multi-step auth), use the "Generic" credential type combined with the Header Parameters section in the node configuration. You can add any custom headers the API requires.

Request Body: Sending Data

When making POST, PUT, or PATCH requests, you need to send data in the request body. The HTTP Request node supports four body content types.

JSON Body

The most common format for modern APIs. Select "JSON" as the body content type and provide your data as key-value pairs or as a raw JSON expression.

Key-value mode is easier for simple payloads: - Key: `name`, Value: `{{$json.firstName}} {{$json.lastName}}` - Key: `email`, Value: `{{$json.email}}` - Key: `company`, Value: `{{$json.company}}`

Raw JSON mode is necessary for nested objects and arrays. Use an expression that builds the JSON structure from previous node data.

Form Data (URL-Encoded)

Used for traditional web form submissions and some older APIs. Select "Form Urlencoded" and provide key-value pairs. The data is encoded as `key1=value1&key2=value2` in the request body.

Multipart Form Data

Required for file uploads. Select "Form-Data" and use the binary data option to attach files from previous nodes. This is how you upload documents to Google Drive, images to an image processing API, or attachments to an email service.

Raw Body

For XML payloads, plain text, or custom formats. Select "Raw" and specify the content type header manually (e.g., `application/xml`, `text/plain`).

Headers and Query Parameters

Custom Headers

Add custom headers for API requirements beyond authentication. Common headers include:

• `Content-Type` — Usually set automatically based on body type, but can be overridden
• `Accept` — Specify the response format you want (e.g., `application/json`, `application/xml`)
• `X-Custom-Header` — Any service-specific headers the API requires
• `User-Agent` — Some APIs require a specific user agent string

Query Parameters

Query parameters are appended to the URL after a `?` symbol. Rather than building the URL string manually (`https://api.example.com/search?q=test&limit=10`), use the Query Parameters section to add them as key-value pairs. This handles URL encoding automatically and keeps the configuration readable.

Common use cases: pagination parameters (`page`, `limit`, `offset`), filter parameters (`status=active`, `created_after=2026-01-01`), and search queries (`q=search term`).

Handling Responses

JSON Responses

Most APIs return JSON. The HTTP Request node automatically parses JSON responses into n8n's data format, making every field accessible in subsequent nodes via expressions like `{{$json.data.id}}` or `{{$json.results[0].name}}`.

Binary Responses

When downloading files (PDFs, images, CSVs), enable the "Response Format" option and select "File." The response is stored as binary data that can be passed to file-writing nodes, email attachment nodes, or other processing nodes.

XML Responses

For APIs that return XML, the node can be configured to convert XML to JSON automatically using the "Response Format" option. The converted JSON follows a standard structure where XML elements become JSON objects and attributes become prefixed properties.

Response Headers

Sometimes you need data from the response headers rather than the body — for example, rate limit remaining counts, pagination cursors, or ETag values. Enable the "Full Response" option to receive both headers and body as separate objects in the output.

Error Handling and Retry Logic

API calls fail. Networks time out, services go down, rate limits get hit. The HTTP Request node provides several mechanisms for handling failures gracefully.

Continue on Fail

Enable "Continue on Fail" to prevent the workflow from stopping when a request fails. The node outputs the error information (status code, error message) instead of throwing an error. Use an IF node after the HTTP Request to check the status code and route successes and failures to different logic paths.

Retry on Fail

Enable "Retry on Fail" to automatically retry failed requests. Configure the maximum number of retries (typically 2-3) and the wait time between retries in milliseconds. For rate-limited APIs, use exponential backoff: first retry after 1 second, second after 4 seconds, third after 16 seconds.

Timeout

Set a request timeout in milliseconds to prevent workflows from hanging on unresponsive APIs. The default is 300 seconds (300000ms). For most API calls, a 30-second timeout (30000ms) is appropriate. For large file uploads or report generation endpoints, increase to 120-300 seconds.

Response Code Validation

By default, the node treats any HTTP response as a success. Enable "Response Code" validation to specify which status codes are considered successful (typically 200-299). Any response outside your specified range triggers an error, which can then be handled by Continue on Fail or Retry on Fail.

Pagination: Handling Large Result Sets

Many APIs limit the number of records returned per request (typically 50-100). To retrieve all records, you need to paginate through multiple requests. The HTTP Request node supports automatic pagination.

Offset-Based Pagination

The most common pattern. Each request returns a page of results plus the total count. You increment the offset by the page size for each subsequent request.

Configure in the "Pagination" section: set the pagination type to "Offset and Limit," specify the parameter names the API uses (commonly `offset` and `limit` or `skip` and `take`), and set the page size. n8n automatically makes multiple requests until all records are retrieved.

Cursor-Based Pagination

Used by modern APIs (Stripe, Shopify, HubSpot v3). Each response includes a cursor token that points to the next page. Configure the pagination type to "Response Contains Next URL" or "Custom" and specify where the cursor appears in the response (typically `data.next_cursor` or a `Link` header).

Page Number Pagination

Some APIs use simple page numbers (`page=1`, `page=2`, etc.). Configure the parameter name and let n8n increment it automatically until an empty response is received.

For APIs returning more than 1,000 records, always use pagination rather than increasing the page size. Large single requests are more likely to timeout, consume more memory, and are harder to retry on failure.

Binary Data and File Handling

Downloading Files

To download a file from an API, set the Response Format to "File" in the node options. The downloaded file is stored as binary data with a default property name of "data." You can rename this property if your workflow handles multiple files simultaneously.

Uploading Files

To upload a file, set the body content type to "Form-Data" and add a parameter with the type set to "Binary Data." Reference the binary property name from the previous node that contains the file. The node automatically handles multipart encoding, content-type headers, and file boundary markers.

Large File Considerations

For files larger than 50MB, consider streaming approaches or chunked uploads if the target API supports them. The HTTP Request node loads the entire response into memory, so very large files may cause memory issues on constrained n8n instances.

Real-World Examples

Example 1 — Fetch All HubSpot Contacts

Method: GET URL: `https://api.hubapi.com/crm/v3/objects/contacts` Auth: OAuth2 (HubSpot credential) Query Params: `limit=100`, `properties=email,firstname,lastname,company` Pagination: Response Contains Next URL (in `paging.next.link`)

Example 2 — Create a Slack Message

Method: POST URL: `https://slack.com/api/chat.postMessage` Auth: Bearer Token (Slack Bot Token) JSON Body: `channel` = `#general`, `text` = `New lead: {{$json.name}} from {{$json.company}}`

Example 3 — Upload a File to Google Drive

Method: POST URL: `https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart` Auth: OAuth2 (Google credential) Body: Form-Data with metadata JSON and binary file data

Example 4 — Call Claude AI API

Method: POST URL: `https://api.anthropic.com/v1/messages` Auth: Header Auth (`x-api-key`) Headers: `anthropic-version` = `2023-06-01` JSON Body: `model` = `claude-sonnet-4-20250514`, `max_tokens` = `1024`, `messages` = array with user message

Example 5 — Stripe: Create a Payment Intent

Method: POST URL: `https://api.stripe.com/v1/payment_intents` Auth: Basic Auth (Secret key as username, empty password) Body: Form Urlencoded — `amount` = `2000`, `currency` = `gbp`, `payment_method_types[]` = `card`

Example 6 — Send a Transactional Email via Resend

Method: POST URL: `https://api.resend.com/emails` Auth: Bearer Token JSON Body: `from` = `PURIST `, `to` = `[{{$json.email}}]`, `subject` = `Your order confirmation`, `html` = `

Thank you

Example 7 — Query a PostgreSQL REST API (Supabase)

Method: GET URL: `https://your-project.supabase.co/rest/v1/orders?status=eq.pending` Auth: Header Auth (`apikey`) Headers: `Authorization` = `Bearer {{$credentials.supabaseServiceKey}}`

Example 8 — Webhook Delivery to External System

Method: POST URL: `{{$json.webhookUrl}}` JSON Body: Full event payload from trigger node Headers: `X-Webhook-Secret` = `{{$env.WEBHOOK_SECRET}}` Timeout: 10000ms (10 seconds — external webhooks should respond quickly)

Advanced Configuration

Batching Requests

When processing multiple items (e.g., updating 500 contacts), the HTTP Request node can be configured to process items individually or in batches. For APIs with rate limits, set the "Batch Size" to 1 and add a "Wait" interval between batches. For APIs that accept bulk operations, use the "Batch Size" to group multiple items into a single request body.

Proxy Configuration

For workflows that need to route requests through a proxy (corporate networks, IP allowlisting), configure the proxy URL in the node's additional options. Supports HTTP and SOCKS5 proxies with optional authentication.

SSL Certificate Handling

By default, the node validates SSL certificates. For internal APIs using self-signed certificates, you can disable SSL verification in the node options. Only do this for internal, trusted endpoints — never disable SSL verification for external API calls.

Redirects

The node follows HTTP redirects (301, 302, 307, 308) automatically by default, up to a maximum of 21 redirects. You can disable redirect following if you need to capture the redirect URL itself (useful for URL shortener resolution or OAuth callback handling).

Performance Optimisation

Connection Reuse

For workflows making many requests to the same API, n8n reuses HTTP connections by default (HTTP keep-alive). This reduces connection setup overhead and improves throughput, especially for HTTPS endpoints where TLS handshakes are expensive.

Response Size Limits

Set the "Max Response Size" in bytes to prevent your workflow from being overwhelmed by unexpectedly large responses. A reasonable default for JSON API responses is 10MB (10485760 bytes). For binary downloads, increase based on expected file sizes.

Parallel Execution

When the HTTP Request node receives multiple input items, it processes them sequentially by default. To process items in parallel (useful when each request is independent), split items into separate branches using the Split In Batches node and recombine the results.

Common Mistakes and How to Avoid Them

Hardcoding Credentials in URLs

Never put API keys in the URL field: `https://api.example.com/data?api_key=sk_live_abc123`. Use n8n credentials instead. This prevents accidental exposure in workflow exports, logs, and error messages.

Ignoring Rate Limits

Most APIs enforce rate limits (e.g., 100 requests per minute). If your workflow processes hundreds of items, add a Wait node between batches or reduce the batch size. Check the API documentation for rate limit headers (`X-RateLimit-Remaining`, `Retry-After`) and build conditional waits based on these values.

Not Handling Pagination

If you request 100 contacts from an API that has 5,000, you get 100 — not an error. Always check if the API response includes pagination indicators and configure the node's pagination settings to retrieve all records.

Assuming JSON Responses

Not every API returns JSON. Some return XML, CSV, or plain text. Check the Content-Type header in the response and configure the appropriate response format in the node options.

Frequently Asked Questions

What is the difference between the HTTP Request node and dedicated service nodes like the Slack node?

Dedicated nodes provide a guided interface with pre-built operations (e.g., "Send Message," "Create Channel"). The HTTP Request node requires you to know the API endpoint, method, and payload structure. Functionally, both achieve the same result. Use dedicated nodes when available for convenience; use HTTP Request for services without a dedicated node or when you need advanced API features the dedicated node does not expose.

Can I use the HTTP Request node to call GraphQL APIs?

Yes. Set the method to POST, the URL to the GraphQL endpoint, and send your GraphQL query in the JSON body with the key "query" containing your GraphQL query string and optionally "variables" for query parameters.

How do I debug HTTP Request node failures?

Enable "Full Response" to see the complete response including status code and headers. Check the execution log for the exact request URL, headers, and body that were sent. Use the "Continue on Fail" option to capture error details without stopping the workflow. For persistent issues, test the same request in a tool like Postman to isolate whether the problem is in n8n configuration or the target API.

Can the HTTP Request node handle WebSocket connections?

No. The HTTP Request node handles standard HTTP request-response patterns. For WebSocket connections, use the n8n Webhook node (for receiving) or a custom Function node with a WebSocket library (for sending). Most real-time integrations can be achieved with polling via the Schedule Trigger plus HTTP Request as an alternative.

Is there a limit on how many HTTP Request nodes I can chain in a single workflow?

There is no hard limit on the number of nodes. However, workflows with more than 50-100 HTTP Request nodes become difficult to maintain. If you find yourself chaining many sequential API calls, consider whether a Function node executing multiple calls programmatically would be cleaner.

How do I send a file from one API to another without saving it locally?

Use two HTTP Request nodes: the first downloads the file with Response Format set to "File," producing binary data. The second uploads that binary data to the target API using Form-Data body type with a binary data parameter referencing the output of the first node. No local file storage is needed.

The HTTP Request node is the single most important node to master in n8n. Once you understand its configuration options, you can integrate any API-based service into your workflows without waiting for dedicated node support. Book a free automation audit and we will show you how to build integrations for your specific tool stack.