N8N + Claude Integration.
Three ways to wire Claude to n8n: push from Claude into a webhook, pull Claude from inside a triggered workflow, or stand up a small wrapper service that both can call. Same three shapes work for every agent stack you'll build. Pick the one that fits the work, not the one that sounds clever.
- Three working integration patterns (push, pull, wrapper service), with the skeleton code for each so you can copy and ship.
- A decision matrix for picking which pattern fits the work in front of you, including cost, latency, and debug tradeoffs.
- A clean line between interactive and triggered work so you stop trying to leave Claude Code running 24/7 to watch for emails.
Pick a pattern with Claude.
Hand the guide off to Claude and have it walk you through choosing the right pattern for one workflow you actually want to build this week.
How this fits in the OS.
An n8n instance you can reach (Cloud or self-hosted), Claude Code installed locally, and an Anthropic API key in Infisical or 1Password.
n8n webhook triggers, schedule triggers, the HTTP Request node, and the Claude API. Optionally a tiny wrapper service on Vercel or your VPS.
Triggered work that runs while you sleep. Claude reasoning inside scheduled workflows. A clean separation between the interactive computer in front of you and the always-on layer behind it.
The shape of the problem.
Claude Code is interactive. You sit down at your computer, you ask for something, it works on it with you. n8n is the opposite. It runs in the background, fires on a schedule or a webhook, and does the work for you while you're doing something else.
You want both. Claude is brilliant for one-off thinking work. You do not want to leave a Claude Code session running 24 hours a day just to watch for new emails. That is what n8n is for.
The pattern most graduates settle on:
- Claude Code drafts the workflow logic during a build session.
- n8n runs it on a schedule or webhook in production.
- Claude Code reviews failures and refactors when something breaks.
That handoff between the two tools has exactly three shapes. They differ in who calls whom, where the prompt lives, and what fails when something goes wrong. The rest of this card walks all three.
A webhook is a URL you POST data to. The other side does work when the URL gets hit. Push a button, something happens. A schedule trigger is the opposite: it fires on a clock (every hour, every day at 9am), no incoming request needed. Both are just ways to start a workflow without a human clicking anything. Most of what follows is just deciding which one to use and where Claude sits in the chain.
The three patterns.
Claude pushes to n8n (the webhook)
What it is. You are sitting in Claude Code. Claude needs to make something happen out in the world: post to Slack, write to a database, kick off a long-running job. Instead of Claude doing it directly, it POSTs to an n8n webhook URL and lets n8n handle the side effect.
When to use it
- The side effect is something n8n already does well (Slack post, Notion update, Airtable write).
- You want one canonical place that talks to that service, so you don't scatter Slack tokens across 15 Claude sessions.
- The work might take longer than Claude wants to wait.
The skeleton
n8n side: a workflow with two nodes. A Webhook node that listens on a path, and a Slack node that uses the payload.
{
"nodes": [
{ "name": "Webhook",
"type": "n8n-nodes-base.webhook",
"parameters": {
"path": "post-to-slack",
"httpMethod": "POST",
"responseMode": "lastNode"
}},
{ "name": "Slack",
"type": "n8n-nodes-base.slack",
"parameters": {
"resource": "message",
"operation": "post",
"channel": "={{ $json.body.channel }}",
"text": "={{ $json.body.text }}"
}}
]
}Claude Code side: just curl.
curl -X POST https://yourname.app.n8n.cloud/webhook/post-to-slack \
-H "Content-Type: application/json" \
-d '{"channel": "#general", "text": "Hello from Claude"}'Tradeoffs
- Cost: near zero. One n8n execution, no Claude tokens spent.
- Latency: roughly 500ms to 2 seconds.
- Debuggability: high. You see the full execution in n8n's Executions log.
- Caveat: webhook URLs are essentially passwords. Use n8n's "Header Auth" or "Basic Auth" on the webhook node for anything sensitive.
n8n pulls Claude (the scheduled API call)
What it is. An n8n workflow needs Claude to do something hard: summarize a document, classify customer feedback, write a draft. The n8n schedule trigger or webhook fires, n8n preps the data, then it calls the Claude API directly from an HTTP Request node. The output flows into the rest of the workflow.
When to use it
- You want Claude's reasoning inside a triggered, scheduled workflow.
- The output needs to flow back into the rest of the n8n workflow.
- You do not want a human in the loop.
The skeleton
Three nodes: a Schedule Trigger, an HTTP Request that fetches data, and a second HTTP Request that calls the Claude API.
{
"nodes": [
{ "name": "Schedule Trigger",
"type": "n8n-nodes-base.scheduleTrigger",
"parameters": {
"rule": { "interval": [{ "field": "hours", "hoursInterval": 1 }] }
}},
{ "name": "Get Recent Tickets",
"type": "n8n-nodes-base.httpRequest",
"parameters": { "url": "https://your-helpdesk.com/api/tickets?status=new" }},
{ "name": "Classify with Claude",
"type": "n8n-nodes-base.httpRequest",
"parameters": {
"method": "POST",
"url": "https://api.anthropic.com/v1/messages",
"authentication": "predefinedCredentialType",
"nodeCredentialType": "anthropicApi",
"sendBody": true,
"bodyParameters": { "parameters": [
{ "name": "model", "value": "claude-sonnet-4-5" },
{ "name": "max_tokens", "value": "1024" },
{ "name": "messages",
"value": "=[{\"role\":\"user\",\"content\":\"Classify this ticket as urgent/normal/spam: {{ $json.body }}\"}]" }
]}
}}
]
}n8n now has a built-in "Anthropic" node (run n8n-cli nodes search anthropic) so you can skip the raw HTTP boilerplate if you prefer. The HTTP Request version is shown here because it works on every n8n version and makes the API call obvious.
Tradeoffs
- Cost: Claude API tokens per execution. Cheap per call, but multiplies with frequency.
- Latency: 2 to 30 seconds, depending on prompt and model.
- Debuggability: medium. n8n shows the request and response, but the prompt itself can get hard to edit inline once it grows past a few sentences.
- Use prompt caching (
cache_control: { type: "ephemeral" }on the system prompt) when the same prompt fires repeatedly.
The wrapper service (the bridge)
What it is. You have outgrown Pattern B. Your prompt is too long to live inside an n8n HTTP body. You need streaming, tool use, or custom retry logic. You build a small Node or Python service that wraps the Claude API, deploy it somewhere (Vercel, Cloud Run, your VPS), and have n8n call your service via HTTP Request.
When to use it
- Your prompt is long enough or complex enough that maintaining it inside an n8n HTTP body is painful.
- You need streaming, tool use, or computer use.
- You want one canonical Claude wrapper that multiple n8n workflows (and other apps) can call.
The skeleton
A tiny Node wrapper, deployed to Vercel as a serverless function. Reads a ticket body, returns a JSON classification.
// api/classify.js
import Anthropic from "@anthropic-ai/sdk";
const anthropic = new Anthropic();
export default async function handler(req, res) {
const { ticket_body } = req.body;
const result = await anthropic.messages.create({
model: "claude-sonnet-4-5",
max_tokens: 1024,
system: [{
type: "text",
text: "You are a ticket classifier. Return JSON: {category, urgency, summary}.",
cache_control: { type: "ephemeral" }
}],
messages: [{ role: "user", content: ticket_body }]
});
res.json(JSON.parse(result.content[0].text));
}n8n side: HTTP Request to https://your-app.vercel.app/api/classify with { ticket_body: "..." }.
Tradeoffs
- Cost: Claude API tokens plus tiny serverless cost (often free tier).
- Latency: same as Pattern B, plus one extra hop (usually under 100ms).
- Debuggability: highest. You control logging, error handling, retries.
- Maintenance: highest. You now own a deployed service.
Side by side.
The same three patterns, scored on the four axes that actually decide which one you pick.
| Pattern | Cost | Latency | Debug | Maintenance |
|---|---|---|---|---|
| A. Push | $ | Low | High | Low |
| B. Pull | $$ | Medium | Medium | Low |
| C. Wrapper | $$ | Medium | Highest | High |
Start with A. Graduate to B when you need scheduled AI. Move to C only when B's prompt-stuffed-into-a-JSON-body gets unwieldy.
Decision matrix.
If you can describe what you're trying to do in one sentence, this table picks the pattern for you.
| What you're trying to do | The pick |
|---|---|
| Claude Code wants to trigger a Slack post | A. Push. Claude calls an n8n webhook. n8n posts. |
| Daily cron that summarizes yesterday's tickets | B. Pull. n8n schedule trigger calls the Claude API node. |
| Customer-facing webhook that needs under 2 seconds with cached prompts and tool use | C. Wrapper. n8n calls your custom service, which calls Claude. |
| One-off "Claude, please do X" with you watching | Just Claude Code. Skip n8n. |
| Same exact transformation on 10,000 records, no judgment needed | Just n8n. Skip Claude. |
What not to do.
Four hard rules. Each one is a mistake someone on this team has already made, so you don't have to.
Where this lives in production.
The three patterns above are the contract. The infrastructure underneath has more to it once you scale past a handful of workflows. Worth a look at what the team's production setup looks like, so you have a target shape in mind.
The team's n8n instance runs on a self-hosted VPS (Hostinger, in the KVM-8 tier) alongside the rest of the agent stack: Postgres for storage, Langfuse for LLM observability, Mattermost for team chat, Neo4j for graph memory, a self-hosted Firecrawl, and a Traefik routing layer in front of all of it. The original reason the VPS exists is n8n. Everything else accreted over time. You do not need any of this on day one. n8n Cloud handles the first dozen workflows fine. The VPS shape becomes useful when you start running enough triggered work that observability and graph memory start mattering more than execution count.
The Anthropic node and HTTP Request node both work identically against Cloud or self-hosted. The patterns in this card do not change. The only thing that changes is where your workflows live and who is responsible for keeping the host alive.
If you're running on n8n Cloud today and wondering when to move: the trigger is usually one of three things. You hit the execution cap on your tier. You need a workflow to reach your local network or internal services. You want the observability stack (Langfuse, Grafana) sitting next to n8n. None of those land on day one.
Where to go next.
You have the three patterns. The natural next moves: