Pre-built integrations are convenient, but the HTTP Request node is where true automation power lies. It is the bridge between n8n and every other piece of software on the web.
1The Anatomy of a Call
Every API interaction follows the same structure. When you use the HTTP Request node, you're acting as a client sending a message to a server. That message has four parts: the Method (GET, POST, PUT, PATCH, DELETE), the URL (the endpoint), the Headers (metadata like Content-Type: application/json and Authorization: Bearer ...), and the Body (the data payload for POST/PUT requests).
Understanding this structure is the universal decoder ring for any API documentation you'll ever read. Every REST API, regardless of what it does ā CRMs, payment systems, AI providers, databases ā follows this same pattern. Once you can translate API docs into an HTTP Request node configuration, you can automate literally anything connected to the internet.
Start with a tool like Postman or the built-in n8n HTTP Request node and test your call manually before embedding it in a workflow. Verify you get a 200 OK response with expected data before adding the surrounding workflow logic.
// GET request: fetch a contact
// Method: GET
// URL: https://api.hubspot.com/crm/v3/contacts/12345
// Headers:
{
"Authorization": "Bearer YOUR_TOKEN",
"Content-Type": "application/json"
}
// No body needed for GET requests
// POST request: create a contact
// Method: POST
// URL: https://api.hubspot.com/crm/v3/contacts
// Body:
{ "properties": { "email": "[email protected]" } }2Auth and Security
The most common reason an HTTP Request fails is authentication. Most APIs require you to prove your identity with every call. There are three main patterns you'll encounter.
Bearer Token (OAuth2): You pass Authorization: Bearer YOUR_TOKEN in the headers. The token is usually short-lived and must be refreshed. n8n can handle this automatically with OAuth2 credentials.
API Key: Simpler than OAuth2. You pass a static key either in a header (X-Api-Key: abc123) or as a query parameter (?api_key=abc123). The key doesn't expire but must be kept secret.
Basic Auth: Base64-encode username:password and pass it as Authorization: Basic encoded_string. Less common in modern APIs but still used.
Never hardcode keys in your workflow. Use n8n's Credentials system ā keys are encrypted at rest and never appear in the workflow JSON. If you export or share a workflow, credentials are stripped automatically.
// Three auth patterns
// 1. Bearer Token
Authorization: Bearer eyJhbGciOiJSUzI1...
// 2. API Key in header
X-Api-Key: sk-prod-abc123xyz
// 3. Basic Auth (base64)
Authorization: Basic dXNlcjpwYXNz
// In n8n: always use Credentials system
// never paste tokens directly in node config
// Credentials are encrypted and never exported3Dynamic Payloads & Error Handling
The real power of the HTTP Request node is dynamic payloads ā building request bodies from data flowing through your workflow. Instead of hardcoded values, you use n8n expressions: {{ $json.email }}, {{ $json.name }}. Every field in the request body can be driven by upstream node data.
This is how you build personalized, contextual API calls at scale: the same node sends a different payload for each item in your workflow's data array. Map webhook input fields to API body fields and you've built a generic integration layer.
Always check the Status Code of the response. A 2xx means success; anything in 4xx or 5xx is a failure. Enable 'Always Return Data' in the node settings to prevent the workflow from stopping on non-200 responses ā then check the status code with an IF node and route errors to your Dead Letter Queue.
// Dynamic payload from workflow data
// n8n HTTP Request - Body (JSON):
{
"email": "{{ $json.email }}",
"firstName": "{{ $json.name.split(' ')[0] }}",
"leadScore": {{ $json.score }},
"source": "{{ $('Webhook').item.json.utm_source }}"
}
// Status code check:
if (response.statusCode >= 400) {
-> Dead Letter Queue
} else {
-> Continue workflow
}