Add x402 to an existing REST API
No MCP required. x402 is plain HTTP, so a payment layer drops in front of the routes you already have — and agents pay per request without ever asking for a key.
Your REST API already does the hard part. What it can't do is serve an anonymous AI agent that has no account, no key, and no human available to fill in a signup form. x402 closes that gap at the protocol level: the agent's first request gets HTTP 402 with a price, the agent pays in USDC, and the retried request goes through.
Crucially, this is additive. Your handlers, your existing key-based customers, and your routes all stay as they are — the payment layer is middleware in front of whichever endpoints you choose to sell per-call.
Why a REST API and not an MCP server?
MCP is one way agents consume services; direct HTTP calls are another, and agent frameworks make them constantly. If your API already has clean REST semantics — a geocoding endpoint, a PDF renderer, a data lookup — you don't need to wrap it in MCP to monetize it for agents. x402 was designed exactly for this: a payment handshake native to HTTP itself, reviving the long-reserved 402 status code.
You can always add an MCP wrapper later for clients that prefer tool-calling semantics. The payment layer you build here carries over unchanged.
The handshake, request by request
Request one: the agent calls GET /v1/geocode with no payment. Your middleware responds 402 with a JSON body listing the accepted payment: amount, USDC as the asset, Base as the network, your receiving address. Request two: the agent retries with an X-PAYMENT header containing a signed transfer authorization. Your middleware forwards it to a facilitator, which verifies and settles — on Base, in roughly two seconds. Then, and only then, the handler runs.
Two requests, no state on your side between them, no chargebacks after. Each settled call produces an Ed25519-signed receipt.
Drop in the middleware
On Express the integration is a per-route middleware. Mount it on the routes you're selling and skip the ones you aren't.
import express from "express";
import { requirePayment } from "@loomal/sdk";
const app = express();
// paid for agents — handler unchanged
app.get("/v1/geocode",
requirePayment({ price: "$0.01" }),
geocodeHandler);
// heavier route, higher price
app.post("/v1/render-pdf",
requirePayment({ price: "$0.10" }),
renderPdfHandler);
// untouched: health checks, docs, existing keyed routes
app.get("/v1/health", healthHandler);Price per route, by what the request costs you
REST APIs rarely have uniform unit economics, so don't quote a uniform price. A cache-served lookup can sit at the $0.01 minimum; a route that fans out to a paid upstream or burns CPU should be priced off its marginal cost with margin on top. Because the price is quoted per 402, different routes — or even different request shapes on one route — can each carry their own number.
Existing customers keep their keys
Adding x402 doesn't migrate anyone. Requests with valid API keys can bypass the payment middleware entirely, so your current contracts and billing keep working while agents pay per call on the same routes. Run both lanes for as long as you like.
When the agent lane is live, list the endpoint on Loomal so agents can discover the URL and price programmatically. The platform fee is 5% on settled transactions, currently waived — there's no charge to maintain the listing itself.
FAQ
Do I have to change my API's response formats?
No. The only new response your API produces is the 402 with payment requirements, and the middleware generates that. Paid requests reach your handlers exactly as before and return whatever they've always returned.
How do agents find out my API accepts x402?
Two ways: any client that hits a priced route discovers it organically via the 402 response, and listing the endpoint on an index like Loomal lets agents find it by searching for the capability before ever making a request.
What if I run something other than Express?
The protocol is framework-agnostic — it's a status code, a JSON payload, and a header. Equivalent middleware exists or is trivially written for Hono, Fastify, Next.js route handlers, and non-Node stacks; the facilitator interaction is a single HTTP POST from any language.
Can a request be partially refunded if my handler fails?
Settlement happens before the handler runs, so build the same reliability you'd want under any billing model: return errors before the payment gate where possible, and keep priced handlers tight. The flip side of no chargebacks is that you should only charge on routes you're confident will deliver.
Your API, now sellable per request.
Mount the middleware, set route prices, and open an agent-facing lane.