Integrating x402 with n8n workflows workflows that pay per call.
n8n can call MCP servers and any HTTP API — but its built-in nodes don't speak HTTP 402. Here's how to handle x402-priced endpoints inside a workflow, and where the wallet should live.
n8n gives you two natural ways to reach external services: the MCP Client Tool node, which lets an AI Agent node use a remote MCP server's tools, and the HTTP Request node for everything else. Both work fine against free endpoints. Against an x402-priced endpoint, both hit the same wall: the server answers 402 Payment Required, and neither node knows what to do with that.
The wall is thinner than it looks. An x402 payment is just a signed retry — receive the 402 terms, sign a USDC authorization, resend with a payment header. A single Code node can do the whole dance, which makes paid endpoints usable anywhere in a workflow.
Why the HTTP Request node alone can't pay
The HTTP Request node treats 402 like any 4xx — an error to throw or to pass along if you enable 'continue on fail.' It has no wallet, so it can't produce the signed payment the retry needs. You could chain nodes to parse the 402 body, but the signature requires key material and an EIP-712 signing step that plain expressions can't perform.
So the pattern is: let a Code node own the paid call end-to-end. Everything upstream and downstream stays ordinary n8n — triggers, transforms, branches — with payment confined to one node you can audit.
The Code node payment pattern
On self-hosted n8n, allow the two required external modules via NODE_FUNCTION_ALLOW_EXTERNAL, then wrap fetch with the x402 payment handler. The wrapper intercepts the 402, signs the USDC authorization from your wallet, retries, and hands back the paid response — one node, no custom infrastructure.
const { privateKeyToAccount } = require("viem/accounts");
const { wrapFetchWithPayment } = require("x402-fetch");
const account = privateKeyToAccount($env.WORKFLOW_WALLET_KEY);
const payingFetch = wrapFetchWithPayment(fetch, account);
const res = await payingFetch("https://api.example.com/score", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify($json),
});
return [{ json: await res.json() }];Keep the key out of the workflow JSON
n8n workflows export, copy, and share as JSON — which is exactly why the wallet key must never appear in a node parameter. Inject it as an environment variable on the n8n host and read it via $env, as the snippet does. Anyone who can read your workflow can then see how you pay, but not pay with your money.
Treat the wallet like the budget it is: fund it with USDC on Base in small amounts (no ETH needed — the facilitator pays gas), alert on the balance, and let the balance act as the hard cap on what any misbehaving workflow can spend. Scheduled workflows deserve special care, since a cron trigger multiplied by a paid call is a recurring cost you set once and forget.
Paid MCP tools and where to find endpoints
The MCP Client Tool node connects an n8n AI Agent to remote MCP servers, and as x402-aware MCP transport support matures, paid MCP tools will slot into that path directly. Today, the dependable route for paid calls is the Code-node pattern above — point it at any x402 endpoint and the agent or workflow gets the result as a normal item.
For supply, browse the Loomal Index: every listing is a priced, payable endpoint with the per-call cost stated up front, which is exactly the information a workflow budget needs. At a minimum price of $0.01 per call, a daily scheduled workflow making one paid call costs about thirty cents a month — and if your workflow produces something valuable, n8n plus a Loomal hosted endpoint also works in reverse: serve your output behind a price.
FAQ
Can n8n Cloud run this, or only self-hosted?
The pattern relies on external npm modules in the Code node, which n8n restricts on Cloud. Self-hosted instances enable it with NODE_FUNCTION_ALLOW_EXTERNAL. On Cloud, the workaround is a small external HTTP service that does the paying, called from a normal HTTP Request node.
Where should the wallet key live?
In an environment variable on the n8n host, read via $env inside the Code node. Never in node parameters — workflow JSON gets exported and shared, and a key embedded there leaks with it.
How do I cap what a scheduled workflow can spend?
The wallet balance is the enforcement layer: fund it with only what the schedule should consume, and top it up deliberately. Add a balance check node before the paid call if you want the workflow to stop gracefully rather than fail when funds run low.
Does the payment add latency to the workflow run?
One extra HTTP round trip plus settlement on Base, which confirms in about two seconds. For typical n8n automations — enrichment, scoring, document processing — it's a negligible share of total run time.
Price what your workflows produce.
List an endpoint on Loomal and let other workflows pay per call.