The problem

You want agent-to-API payment to work, but which problem you have depends on which side you are on. Maybe you build agents and want them to pay the APIs they call, settling per use rather than stalling at a paywall. Or maybe you run an API and want agents to pay you for it, turning usage into revenue from machine callers. Either way, the question is the same relationship from two ends: how does an agent pay an API, and how does an API charge an agent?

This is the agent-to-API payment problem, and the useful framing is that it has two sides that fit together. Solving it means setting up the side you are on, the pay side if your agent consumes APIs, the receive side if your API serves agents, knowing that the two are designed to meet. The symptom is wanting agent-to-API payment without a clear picture of the pieces; the fix is to understand both sides and wire the one you need.

Two sides of the relationship

Agent-to-API payment is a two-sided relationship. On one side is the agent that wants to pay for an API call; on the other is the API that wants to charge for it. The two meet at a single moment: the agent calls the API, the API responds that payment is required, the agent pays, and the API serves the result. Each side has a job, the agent settles the payment, the API gates and verifies it, and when both do their job, the call completes paid.

Seeing it as two sides clarifies what to build. If you are the agent builder, you build the pay side and rely on the API to gate; if you are the API builder, you build the receive side and rely on the agent to pay. You rarely build both unless you run agents that pay your own APIs. So the first step in solving agent-to-API payment is identifying your side, because that tells you which of the two setups below applies to you.

The pay side

The pay side is the agent paying the API. You give the agent a funded wallet, a spend limit, and a tool built on createX402Client from @blockchain0x/x402. When the agent calls an x402-enabled API and receives an HTTP 402, the client reads the price, settles the amount in USDC on Base, and retries the request, returning the data. The agent pays per call, within its spend limit, with no signup at the API.

import { createClient } from "@blockchain0x/node";
import { createX402Client } from "@blockchain0x/x402/client";
const sdk = createClient({ apiKey: process.env.B0X_API_KEY! });
const fetchWithPay = createX402Client({ sdk });
const res = await fetchWithPay("https://api.example.com/paid-endpoint"); // 402 settled + retried

That is the agent side complete: with the wallet funded, the limit set, and the client wrapped in a tool, the agent can pay any API that speaks x402. The full walkthrough is in how-to-add-usdc-payments-to-ai-agent. For Python frameworks, the same client runs behind a small local proxy the agent's tool calls.

The receive side

The receive side is the API charging the agent. You gate the API's route with the x402 adapter, createX402Plugin (Fastify) or createX402Middleware (Express), with per-route pricing, so an unpaid call gets a 402 and a paid one settles in USDC before your handler runs.

import Fastify from "fastify";
import { createClient } from "@blockchain0x/node";
import { createX402Plugin } from "@blockchain0x/x402/server/fastify";
const sdk = createClient({ apiKey: process.env.B0X_API_KEY! });
const app = Fastify();
await app.register(createX402Plugin, {
  sdk, defaultNetwork: "testnet",
  pricing: { "GET /data": { amountUsdc: "0.01", payToAddress: process.env.B0X_PAYTO_ADDRESS!, paymentRequestId: "pr_data" } },
});

Now any agent with an x402 client can pay your API per call, with no signup required of the caller, and a payment.received event confirms each payment. That is the API side complete. Keep a free discovery route so callers can see what the API offers before paying, and see best-way-to-accept-payment-from-ai-agent for the broader receive-side options.

They meet over x402

The reason the two sides fit together is that both run on x402, an open protocol. The agent's client and the API's gate speak the same wire format, the 402 with its price, the X-Payment header on the retry, settlement in USDC, so they interoperate without coordination. You do not have to build both sides or match vendors; you build your side to the protocol, and it works with any compliant counterparty on the other.

This is what makes agent-to-API payment scalable rather than a series of bespoke integrations. An agent built on one platform can pay an API gated on another, because x402 is the shared standard between them, the way any web browser talks to any web server. So solving your side of agent-to-API payment also connects you to every other x402 party: an agent you build can pay any x402 API, and an API you gate can be paid by any x402 agent. The open protocol is the meeting point, which is why building to it is the durable fix.

Setup checklist

To make agent-to-API payment work, run the checklist for your side. On the pay side: create and fund the agent's wallet, set a spend limit, wrap createX402Client in a tool, and confirm a paid call on Base Sepolia. On the receive side: gate your route with the adapter and a price, leave a free discovery route, set up the payment.received webhook, and confirm an unpaid call gets a 402 while a paid one runs.

For both sides, test on Base Sepolia with sk_test_ keys first, then swap to sk_live_ for mainnet, since the network is read from the key prefix. If you run agents that pay your own APIs, do both checklists, and you will see the agent pay and the API receive in one loop. Working through the checklist for your side turns the agent-to-API payment relationship from a concept into a verified, paid call, which is exactly the fix the problem calls for.

Why this is a new kind of API relationship

It is worth noting that agent-to-API payment changes the relationship between an API and its callers. Traditionally, using an API meant signing up, getting a key, and often committing to a plan, a relationship established before the first call. Agent-to-API payment over x402 removes that prelude: a caller the API has never seen pays for one call and is served, with no account and no commitment. The relationship is per call, established and settled in the moment.

That shift matters on both sides. For an API, it opens a market of callers, every capable agent, not only those who completed a signup, and turns usage directly into revenue. For an agent, it removes the onboarding friction that would otherwise block it from using an API mid-task, since it can pay on first contact. So agent-to-API payment is not just a billing mechanism bolted onto the old relationship; it is a different relationship, signup-free and per-call, which is why it suits a world of autonomous agents consuming APIs they discover as they work rather than ones a human pre-registered for.

Related reading

For the pay side, the full walkthrough is in how-to-add-usdc-payments-to-ai-agent. For the receive side, the options are in best-way-to-accept-payment-from-ai-agent. Together they cover both ends of agent-to-API payment, which meet over the open x402 protocol. Pricing is on the pricing page.