x402 Bazaar: how agents find and pay for APIs on their own

x402 answers "how does an agent pay for an API." The Bazaar answers the question that comes first: which API, at what price, with what input schema — and it lets the agent find out at runtime instead of at build time.

We have spent a run of posts on the payment side of agent commerce. x402 turns an HTTP 402 into a settleable payment. EIP-3009 is the gasless primitive underneath it. The A2A x402 extension lets one agent charge another. All of it assumes the agent already knows where to go. That assumption is the last hand-hold left in "autonomous" commerce: a human still had to pick the endpoint, get the key, and wire it in.

The Bazaar is Coinbase's attempt to remove that hand-hold. It is the discovery layer of x402 — a catalog of payable endpoints that agents can search, price, and call without any pre-baked integration. This post reads it end to end from the CDP documentation and the reference SDK.

What the Bazaar actually is

Think yellow pages for the agentic web, built for machines rather than humans. The Bazaar indexes x402-enabled endpoints together with their payment metadata — network, asset, price, recipient — and, where the seller declares it, the input and output schema of the endpoint. An agent that can query that index can go from "I need weather data" to a paid, structured response without a developer ever touching the code path.

The index is populated and served by the CDP Facilitator. This matters for the mental model: in x402 the facilitator is the party that runs /verify and /settle against the chain on behalf of a resource server. The Bazaar rides on that same facilitator. Because the facilitator already sees every payment, it is positioned to catalog every endpoint it settles for — discovery falls out of settlement as a side effect.

No registration step: you get indexed by getting paid

The design decision that makes the Bazaar interesting is that there is no submit form. You do not register an endpoint. The CDP Facilitator catalogs your service the first time it settles a payment for that endpoint.

The consequence is subtle and worth stating plainly: a brand-new priced endpoint is invisible until it takes its first real payment. There is a bootstrap step where you (or a test agent) pay your own endpoint once to seed it into the catalog. After that, the listing persists — though endpoints with no activity in the last 30 days are dropped from the catalog, so a service that stops being used quietly disappears.

The facilitator signals whether it accepted your discovery metadata through an EXTENSION-RESPONSES header on the verify/settle response, with a status of processing or rejected. That is the diagnostic you reach for when an endpoint settles but never shows up. It is also, as of this writing, a known sore spot — issue 2112 in the x402 repo reports the CDP facilitator not emitting the header at all, leaving sellers with settled payments and no way to tell why their service is missing from the index. Read that as a maturity signal, not a dealbreaker: the extension is codified but the operational plumbing is still being hardened.

Three HTTP surfaces, one index

All of it hangs off the CDP base https://api.cdp.coinbase.com/platform/v2/x402. Three read surfaces expose the same catalog for different access patterns.

Every listing carries the same core shape: resource (the endpoint URL), type (currently "http"), x402Version, an accepts array of payment requirements — scheme, network, amount, asset, payTo — a lastUpdated timestamp, and optional metadata with the description and schemas. The accepts array is the load-bearing field: it is the same PaymentRequirements the agent will echo back inside its x402 payment, so discovery and payment share one vocabulary.

The discovery MCP server

The fourth surface is not HTTP-shaped at all. At /discovery/mcp the Bazaar exposes an MCP server, so an agent can treat discovery-and-pay as ordinary tool calls. It offers two tools:

• search_resources — semantic discovery over the index, returning descriptions, pricing, and schemas ranked by relevance. The same search surface, wrapped as a tool.
• proxy_tool_call — invoke a discovered resource by name and arguments. This is the payoff: the agent does not just learn the endpoint exists, it calls it through the proxy.

The x402 MCP client wrapper closes the loop on payment. When proxy_tool_call hits a 402, the wrapper builds the payment payload, attaches it to the MCP request's _meta field, and retries transparently — the agent's tool call succeeds without the model ever seeing a payment error.

const paymentClient = new CdpX402Client();
const client = createX402MCPClient(mcpClient, paymentClient, { autoPayment: true });

// search_resources finds it, proxy_tool_call calls it,
// the wrapper pays the 402 and retries — one tool call to the model.

This is the same "keys stay out of the model" discipline we flagged in the A2A x402 post, applied to discovery. The model reasons about which tool to call; the wrapper handles the signing and the retry.

Declaring a resource as a seller

Making an endpoint discoverable is three moving parts in the reference SDK (@x402/extensions/bazaar, with a Go equivalent at github.com/coinbase/x402/go/extensions/bazaar covering both v1 and v2). You wrap the facilitator client with withBazaar(), register bazaarResourceServerExtension, and attach declareDiscoveryExtension() to each route you want listed.

import { declareDiscoveryExtension } from '@x402/extensions/bazaar';

"GET /weather": {
  accepts: [{ scheme: "exact", price: "$0.001", network: "eip155:8453", payTo: "0xYourAddress" }],
  description: "Get real-time weather data",
  mimeType: "application/json",
  extensions: {
    ...declareDiscoveryExtension({
      input: { city: "San Francisco" },
      inputSchema: {
        properties: { city: { type: "string", description: "City name" } },
        required: ["city"],
      },
    }),
  },
}

Validation is strict on the way in. The declared input must pass JSON Schema validation against the schema you supply, and descriptions are capped at 500 characters. This is deliberate: the whole value of a discovery index is that a machine can trust the schema it reads, so the facilitator refuses declarations that lie about their own shape. On the facilitator side, helpers like extractDiscoveryInfo() (Go: ExtractDiscoveredResourceFromPaymentPayload, ValidateAndExtract) pull that metadata out of the settled payment.

Querying it as a buyer

The buyer side is smaller. Wrap the facilitator client with withBazaar() and call listResources through the discovery extension. Filtering by price is plain array work, because accepts.amount is right there in the listing.

import { HTTPFacilitatorClient } from '@x402/core/http';
import { withBazaar } from '@x402/extensions/bazaar';

const facilitator = withBazaar(
  new HTTPFacilitatorClient({ url: "https://api.cdp.coinbase.com/platform/v2/x402" })
);

const discovery = await facilitator.extensions.discovery.listResources({ type: "http", limit: 20 });

// Keep only endpoints under $0.10 (amount is in atomic units)
const affordable = discovery.items.filter((i) =>
  i.accepts.some((req) => Number(req.amount) < 100000)
);

Note the second argument to listResources: type is a filter. type: "http" returns HTTP endpoints; type: "mcp" returns discoverable MCP tools. The catalog is not just REST endpoints — it is the substrate for an agent to find other agents' tools too.

Trust, ranking, and where it cracks

Discovery without trust is a spam magnet. The Bazaar leans on the one thing it has that a plain registry does not: settlement history. Search ranking blends retrieval relevance with objective quality signals — buyer reach, transaction volume, recency, metadata quality — and those metrics are recomputed on a six-hour schedule. An endpoint that many distinct agents actually pay for ranks above one that merely exists. On-chain payment becomes a Sybil-resistant reputation signal, because faking it costs real USDC.

That is a genuinely nice property, and it is also where the honesty has to come in. The ranking is CDP's, computed inside CDP's facilitator, over CDP-settled payments. The Bazaar today is a Coinbase product, not a neutral protocol layer. The EXTENSION-RESPONSES gap in issue 2112 is a reminder that the operational surface is young. And the 30-day activity cutoff plus six-hour ranking lag mean the catalog is a moving, opinionated view, not a durable ledger. For a settlement-grade trust layer you want something closer to ERC-8004's on-chain reputation registry. The Bazaar is the fast, useful, centralized version of that idea — excellent for finding endpoints today, not the thing you anchor long-term identity to.

What it means for LLM4Agents

Our stack already has the two neighbors of discovery. The gateway is an x402-priced, OpenAI-compatible surface — a payable endpoint. Our MCP server exposes tools an agent can call. The Bazaar sits exactly between them: it is how an agent that has never heard of us could discover the gateway, read its price and schema, and start paying — with no onboarding, no key issuance, no human in the loop.

That is a distribution channel we do not control but should be present in. If autonomous buyers increasingly start from a discovery query rather than a hardcoded base URL, then not being in the index means not being reachable by the fastest-growing class of customer. The flip side is a threat model: a discovery layer that ranks by settlement volume rewards whoever settles the most through a single facilitator, which is a soft centralizing pressure toward CDP. LLM4Agents settles across multiple chains and rails; we should make sure our discoverability never depends on routing all settlement through one party's facilitator.

Staying on the frontier

Concrete moves, in order.

First, get indexed. Attach declareDiscoveryExtension() to the priced gateway routes and the MCP tools, seed each with one real settlement, and confirm the EXTENSION-RESPONSES status comes back processing. If it silently fails — the issue-2112 case — file against it and keep the receipts, because being in the catalog is table stakes.

Second, publish honest schemas. The ranking rewards metadata quality and the validator rejects lies. Declare the real input and output schemas for every discoverable route so an agent that finds us can call us correctly on the first try. A clean schema is a conversion optimization for machine buyers.

Third, run a buyer-side Bazaar client, not just a seller listing. The same discovery index lets our own agents find third-party tools to compose. Wire withBazaar() and proxy_tool_call into the agent runtime so a fleet can discover-and-pay for capabilities we do not host, priced per call in stablecoins.

Fourth, do not let discovery become lock-in. Treat the CDP Bazaar as one index among several. Keep our own canonical, self-hosted catalog of what we sell, mirror into CDP for reach, and track ERC-8004 so that when a neutral, on-chain discovery-and-reputation layer matures, our identity and history port to it instead of being trapped in one facilitator's ranking.