Workflow Automation Platforms
How do I connect a custom API in n8n using the HTTP Request node and import a cURL command?
6 min read
Most teams hit the limits of “pre-built” integrations sooner than they expect. When that happens in n8n, the HTTP Request node is your escape hatch: it lets you call any HTTP-based API directly, and you can even import an existing cURL command instead of rebuilding it by hand.
Quick Answer: To connect a custom API in n8n, add an HTTP Request node, paste your API endpoint and method, configure authentication and headers, and test the request. If you already have a cURL command, use the “Import from cURL” option to automatically populate the node settings.
Frequently Asked Questions
How do I connect a custom API in n8n using the HTTP Request node?
Short Answer: Add an HTTP Request node to your workflow, configure the URL, method, authentication, and headers/body, then run the node to test the integration.
Expanded Explanation:
The HTTP Request node is n8n’s generic connector for any REST-ish API. You drop it into your workflow, point it at the API endpoint, set the HTTP method (GET, POST, PUT, etc.), and configure the request details—query parameters, headers, body, and auth. Once it’s configured, you can test the node in isolation, inspect inputs/outputs, and then wire it into the rest of your workflow.
You’ll need basic API terminology (endpoints, methods, headers, JSON) and access to the API’s documentation. If the vendor doesn’t have a dedicated n8n node yet, this is how you integrate them without building a custom service from scratch.
Key Takeaways:
- Use the HTTP Request node whenever you need to talk to an API without a dedicated n8n node.
- Configure URL, method, auth, headers, and body, then run and inspect the node to validate the integration.
How do I import an existing cURL command into the HTTP Request node?
Short Answer: In the HTTP Request node, use the “Import from cURL” function, paste your full cURL command, and n8n will map it to the node’s settings.
Expanded Explanation:
If you already have a working cURL command (from docs, Postman, or your terminal), you don’t need to manually re-create every header and parameter. Instead, you can import the cURL command into the HTTP Request node. n8n parses the command and fills in the key fields: HTTP method, URL, headers (including auth if present), query parameters, and request body.
After import, you should review the node configuration to clean up sensitive values (e.g., move API keys into Credentials or environment variables) and parametrize anything you want to drive from earlier nodes. Then run the node once to make sure the behavior matches your original cURL call.
Steps:
- Add an HTTP Request node to your workflow and open its settings.
- Click the option to “Import from cURL” (often found near the URL/method section), then paste your full cURL command.
- Confirm the parsed values, move secrets into Credentials, and run the node to test.
What’s the difference between using a pre-built node and the HTTP Request node for APIs?
Short Answer: Pre-built nodes give you guided, higher-level actions; the HTTP Request node gives you full control over any API, even if there’s no dedicated node.
Expanded Explanation:
Pre-built nodes (like Slack, Postgres, or Gong) expose common actions through a UI: you pick an operation from a dropdown, fill a few fields, and n8n handles the request structure. They’re faster when your use case fits what the node exposes.
The HTTP Request node is more low-level. You define the entire HTTP call: endpoint, method, headers, auth, and body. This is ideal when:
- There’s no native node yet.
- The API has advanced options not exposed by the node.
- You need to debug exactly what’s being sent.
In practice, many production workflows combine both: pre-built nodes for routine actions, HTTP Request for edge cases and new APIs.
Comparison Snapshot:
- Option A: Pre-built node: Simplified UI, opinionated operations, less manual setup.
- Option B: HTTP Request node: Full flexibility, works with any REST API, more configuration.
- Best for: Pre-built nodes for common patterns; HTTP Request when you need custom APIs or fine-grained control.
How do I safely handle authentication and secrets with a custom API?
Short Answer: Use n8n Credentials and encrypted secret storage for API keys or tokens, and reference those in your HTTP Request node instead of hardcoding secrets.
Expanded Explanation:
Hardcoding secrets directly into HTTP headers or URLs is a fast way to create an incident. In n8n, you should manage auth via dedicated Credential types (API key, OAuth2, Basic Auth, generic token, etc.). These are stored in an encrypted secret store and can be reused across workflows.
When you import a cURL command that includes authentication headers, treat that as a one-time bootstrap: move the raw key into a Credential and replace the header value with a reference to that Credential. In enterprise environments, combine this with SSO (SAML/LDAP), RBAC, and audit logs so you can control who can read or modify credentials and track changes.
What You Need:
- An appropriate Credential type in n8n (API key, OAuth2, etc.) configured with your secret values.
- A policy to avoid pasting raw secrets into node fields or workflow JSON; use Credentials and environments instead.
How does connecting a custom API with the HTTP Request node fit into an overall automation strategy?
Short Answer: Using the HTTP Request node for custom APIs lets you standardize on n8n as your automation layer, avoid one-off custom services, and keep everything auditable, testable, and versioned.
Expanded Explanation:
From a platform engineer’s perspective, every “quick custom integration” written as a standalone script becomes another thing to monitor, patch, and debug. By using the HTTP Request node for custom APIs, you keep all automation inside a single workflow engine with shared controls: executions, logs, retries, error workflows, and Git-based version control.
This is especially important when you start injecting AI into these flows. You can call LLM providers via HTTP Request, but do it inside a workflow that has guardrails: test with real data, evaluate outputs, add human-in-the-loop approval steps, and use workflow history to understand failures. Pair that with enterprise controls like RBAC, audit logs, log streaming to your SIEM, and environments so you maintain operational rigor as complexity grows.
Why It Matters:
- Reduces “integration sprawl” by consolidating custom API calls into n8n workflows with logs, history, and Git diffs.
- Keeps AI and non-AI integrations under the same governance model, so you can move fast without creating future incidents.
Quick Recap
To connect a custom API in n8n, you use the HTTP Request node as your generic connector: configure the endpoint, method, auth, headers, and body, or import a working cURL command to bootstrap those settings. Move secrets into n8n Credentials, test the node with real data, and wire it into workflows that you can rerun, inspect, and version. This lets you integrate any HTTP-based service—AI or otherwise—without leaving the guardrails of a proper automation platform.