Letting Agents Pay for Data with x402

An agent needs data to finish a task, but the API charges for access. How can it buy what it needs without a person setting up a subscription or giving it an open-ended spending budget?

I explored this by integrating x402 into a paid data API and testing the payment path end to end with real USDC. A client could request data, receive a price, authorize payment, and get the response.

Getting that request to work left three questions: how to enforce the agent's budget, how to recover when a request times out after payment, and how to tell whether the data was worth buying.

This post follows the payment through one request, then works outward to the buyer I would build around it. The payment flow is working. The spending controls and evaluation loop below are the next design, not results I have already measured.

What x402 Adds to an HTTP Request

Suppose an agent needs one piece of data from an API it has never used before. A normal integration might require an account, a billing setup, an API key, and a decision about which subscription tier to buy. That is a lot of setup for one answer.

With x402, the server can put a price on the request itself. The client receives 402 Payment Required with machine-readable payment terms. It can decide whether to accept them and retry with a signed payment payload. The server verifies and settles the payment before returning the paid response. This is the basic client/server model.

The useful change is where the purchase happens. An agent can encounter a paid resource while doing a task and buy access through the same request flow. The provider does not need a separate billing relationship with every possible caller.

That makes small, occasional purchases worth exploring. It does not make them free. Network costs and facilitator pricing still belong in the economics, along with the cost of producing the data. I would measure those against the intended request volume before choosing a price.

Following One Payment

The diagram shows a successful fixed-price request through a facilitator. It leaves out error branches so the roles are visible.

The HTTP v2 transport uses three headers:

Header	Direction	What it carries
PAYMENT-REQUIRED	Server to client	The payment requirements, including the accepted payment options
PAYMENT-SIGNATURE	Client to server	The payment payload for the selected option
PAYMENT-RESPONSE	Server to client	The settlement result

The objects are Base64-encoded JSON. Base64 is encoding, not encryption. The HTTP transport specification defines these headers; the resource body remains the application's concern. These are v2 names used to explain the protocol, rather than a capture of my deployment.

The facilitator handles payment verification and settlement for the server. In the documented flow, verification happens before the server performs the work. Settlement then happens before it returns the result. The facilitator submits the transaction and reports its outcome. It does not hold the buyer's funds in escrow or judge the data. Servers can also handle verification and settlement themselves. See the facilitator flow.

For an EVM payment using a token that supports ERC-3009, the client can sign an authorization off-chain. It binds a transfer to a recipient and amount, with a validity window and a nonce. A submitting party can pay the gas to execute it. The payer does not have to send a separate gas-funded transaction for that transfer. ERC-3009 specifies that authorization mechanism.

This is one payment path, not the definition of all x402 payments. The protocol supports different schemes and networks. Wallet compatibility has to be checked against the chosen path.

A Price Is Not a Spending Policy

The server tells the client what a request costs. That price says nothing about whether I wanted the agent to buy it.

Suppose I give an agent a task budget of 2 USDC and allow requests up to 0.10 USDC each. Those are two separate limits. A loop making 100 purchases at 0.03 USDC passes the per-request check every time and still spends 3 USDC.

Concurrency makes the same mistake less obvious. If two workers each see 0.05 USDC remaining, both might approve a 0.03 USDC purchase. Reading the balance before signing is not enough. The budget check needs to reserve the amount atomically so that an in-flight purchase reduces what the next worker can spend.

For an initial buyer, I would make the rules explicit:

Rule	Example	Where I would enforce it
Per-purchase limit	At most 0.10 USDC	Payment authorization service
Total task budget	At most 2 USDC, including pending purchases	Shared budget ledger with atomic reservations
Approved provider	Known endpoint and expected payment recipient	Request validation before signing
Payment asset	Expected token contract on the expected network	Payment-term validation
Expiry	No new purchases after the task deadline	Authorization service and compatible wallet permissions

These numbers are illustrative, rather than prices from the deployment.

I would bind an approval to the actual purchase: the resource, request parameters, recipient, asset, network, and amount. Approving a domain and then signing whatever payment terms it returns leaves too much room for the purchase to change underneath the approval.

Put the Limit Where the Agent Cannot Rewrite It

A prompt saying "do not spend more than 2 USDC" is useful context. I would not count it as enforcement.

If the agent can access an unrestricted signing key, it can bypass a proxy that refuses the purchase. Moving the check into a separate service only helps if the agent cannot also reach the key or change that service's policy.

The boundary I want looks like this:

The agent proposes a purchase. A separate service validates the payment terms, reserves the budget, and obtains a signature using the authority it has been granted. The agent receives a result or a refusal. It does not get the owner's key.

Where the wallet supports it, I would also constrain that service's authority at the account level. Coinbase's Spend Permissions are an example of the underlying primitive: delegate spending for a token to a spender under an allowance and time period, with revocation. That gives the owner a limit outside the agent's reasoning loop.

There is an integration detail here that is easy to skip. A wallet permission and an x402 payment authorization are different things. A recurring allowance does not automatically enforce an API allowlist, a per-request ceiling, or the meaning of "only buy useful research." Nor does every smart account work with every token's signature verification path. The x402 wallet compatibility guide describes why the signer, scheme, and token have to fit together.

I would verify that combination before calling the design bounded. The effective limit is the one every spending path has to pass through.

An LLM could help decide whether an offer sounds relevant to the task. It should have no authority to raise the numeric cap. That decision is especially important when the text it is judging came from the seller.

Retries Need to Remember the Purchase

Now suppose payment succeeds and the connection drops before the agent receives the data. From the caller's perspective, the tool failed. From the payment system's perspective, money may already have moved.

Signing a fresh payment on every retry can turn a transient network problem into repeated purchases. A token authorization's nonce helps prevent reuse of that same authorization. It does not stop a client from creating another authorization for the same logical request.

x402 has a payment-identifier extension for idempotency. With corresponding server-side deduplication and response caching, a retry can refer to an existing purchase rather than process another payment. Adding an identifier on the client alone is not enough; the server has to honor it.

My buyer would keep a purchase record with a stable ID and track the authorization, settlement, and delivery separately. An ambiguous timeout would leave the budget reserved until the payment state was reconciled. Refunding the local budget immediately would make money available to spend again even though the original payment might still complete.

This is also why I want an audit trail at the task level. A list of blockchain transactions can tell me where money went. I still need to connect each transfer to the request that caused it and the response the agent actually used.

A Paid Response Can Still Be Useless

A settled payment tells me that the transfer completed. It does not tell me whether the data is fresh, correct, or relevant.

For a research query, a provider could return valid JSON containing last month's announcements. The HTTP request succeeds. The payment succeeds. The research task still gets a poor input.

I would start by checking things that have reasonably clear answers:

• Does the response match the promised schema?
• Are the records within the requested time window?
• Do the records include sources I can inspect?
• Did this purchase add information the task did not already have?

The first two are easier to automate than the last two. A timestamp supplied by the seller is a freshness claim, not independent verification. Schema validity is useful, but stale information can fit a schema perfectly.

Discovery is already part of the ecosystem. The Bazaar extension lets services publish machine-readable descriptions, pricing, and schemas for buyers to find. That is a useful starting point for selecting candidates. I would still need to evaluate the responses after buying them.

The metric I care about is cost per useful task result. A cheap response that the agent discards is still a cost. A more expensive response could be the better purchase if it avoids several searches and supplies the missing evidence. That is a hypothesis to test on actual tasks, not a reason to assume the agent will shop well.

The Next Thing I Would Build

I would start with a small buyer against the endpoint I already operate. One provider keeps the first experiment understandable. It also means a successful test says little about choosing between independent sellers, which would come later.

The tool interface could be as small as:

paid_search(question, max_spend)
  -> answer + sources + purchase_id + amount_paid

This is a proposed interface. The caller's max_spend would only narrow the owner's budget. Asking for a larger number would never grant the agent more money.

Behind that tool, I would implement the payment flow and budget ledger before adding provider ranking. I would test a normal purchase, an over-budget refusal, concurrent purchases near the cap, a changed payment recipient, and a dropped connection after settlement. Then I would deliberately return stale or irrelevant data and check that the task evaluation notices.

For the usefulness experiment, I would compare the same research tasks with and without paid access. Keep the model and evaluation criteria fixed. Record the purchase cost, the rest of the task's cost, and whether the final answer gained usable evidence. I would inspect the failures as closely as the successful purchases.

Only after that would I add more providers. An index, dynamic pricing, or a publication that buys its own sources could all be interesting extensions. None of them answers the first question for me: did buying this data improve the work?

The end-to-end USDC test gave me a working payment path. The next milestone is a buyer that stays inside its budget, survives an uncertain response, and can show what it got for the money.