The x402 Bazaar Problem: How AI Agents Discover Paid APIs

Key takeaways

• A valid x402 payment flow does not automatically distribute or rank an endpoint.
• Coinbase CDP Bazaar currently combines semantic search, structured filters, quality signals, and MCP access.
• CDP has no separate seller submission endpoint: a valid Bazaar extension is indexed asynchronously after successful settlement through the CDP facilitator.
• PayAI discovery, x402scan, OpenAPI, the MCP Registry, and future indexes are separate publication channels.
• Access402’s role is seller-side distribution: describe a resource once, publish it to supported channels, monitor it, and let the seller remove it later.

A payable API can still be invisible

While building Access402, I started with the payment flow. How does an API return HTTP 402 Payment Required? Which facilitator verifies and settles the authorization? How does the seller receive USDC?

Then I reached the more important distribution question: how does an agent know the endpoint exists? An x402-compatible client can pay a known URL, but the protocol response does not by itself place that URL into every catalog, search engine, agent tool registry, or model context.

That distinction matters. Payment infrastructure converts demand into a transaction. Discovery infrastructure creates the opportunity for demand to exist in the first place.

What is an x402 Bazaar?

An x402 Bazaar is a searchable catalog of APIs, content, MCP tools, and other resources that accept x402 payments. A useful listing describes what the resource does, its stable URL and HTTP method, what it costs, the networks and assets it accepts, which inputs it requires, and what it returns.

In the ideal experience, an agent asks for a weather API that supports Boston and costs less than one cent. The discovery layer finds compatible resources, maps the request to the declared input schema, presents the price and relevant trust signals, and gives the agent enough information to call and pay for the endpoint.

The Bazaar extension is now part of x402 version 2. Resource servers declare input and output metadata, while a compatible facilitator validates and catalogs that declaration. The extension creates a common vocabulary, but it does not create one universal database.

Coinbase CDP Bazaar is currently the most complete implementation

Coinbase CDP Bazaar currently offers the strongest documented search surface I have found. It supports a paginated resource catalog, semantic search, structured filters, quality-informed ranking, merchant lookup, and an MCP server that exposes search_resources and proxy_tool_call to agents.

Its ranking combines retrieval relevance with signals the CDP facilitator can observe, including distinct buyers, successful transaction volume, recency, and metadata completeness. This is materially more useful than a flat list because an agent can search for a capability instead of already knowing the endpoint URL.

Publishing is deliberately tied to settlement. A seller includes a valid x402 v2 Bazaar extension and processes the route through the CDP facilitator. Verify alone is not enough. After the first successful settlement, CDP asynchronously catalogs the metadata; there is no separate registration API that guarantees immediate admission.

That last point creates a practical bootstrap problem: a new endpoint may need a successful paid call before it can appear in the discovery system intended to generate paid calls. Sellers also need to inspect extension responses and search results because an accepted or processing status does not by itself prove that a listing is searchable.

An open protocol can still produce concentrated discovery

x402 is open, but each Bazaar remains an operated index. The index operator decides which declarations it accepts, which signals influence ranking, how frequently entries are refreshed, and when a listing is removed. That is normal for a search product, but it means facilitators can gain influence beyond payment verification and settlement.

Coinbase’s position is not evidence of bad behavior. It is evidence that discovery is valuable. If a large share of agents query one index, inclusion and ranking in that index become commercially important even though sellers remain free to use the underlying protocol elsewhere.

The healthier long-term outcome is multiple interoperable discovery channels rather than one mandatory catalog. Competition can produce different ranking models, audiences, trust signals, commercial policies, and routes into agent runtimes.

The alternatives are useful, but they are not one marketplace

PayAI documents a paginated discovery API for listing x402 resources. That provides a programmatic catalog, but it is a separate index with its own facilitator context and publication lifecycle. A resource visible there is not automatically visible in CDP Bazaar.

x402scan takes a different approach. Its preferred discovery contract is an OpenAPI document at /openapi.json, supplemented by a live probe that checks whether the route returns a valid 402 challenge. This is valuable because OpenAPI can describe an entire service independently of one facilitator, but publishing an OpenAPI document still does not place the endpoint into every Bazaar.

The official MCP Registry is another distribution channel for publicly available MCP servers. It can help clients find a server, while an x402 Bazaar can help agents find and pay for individual resources or tools. Those concerns overlap, but the registries, publication formats, and removal rules are not the same.

AWS Bedrock AgentCore illustrates both the reach and the concentration. AgentCore Gateway can connect directly to Coinbase’s Bazaar MCP server, giving AWS agents access to Coinbase-indexed paid tools. That expands distribution for those listings, but it is consumption of the Coinbase index—not a new independent x402 index.

Cloudflare, Amazon, and Google are positioned to shape discovery

Cloudflare is an obvious candidate for broader x402 discovery. It already documents x402 support for paid HTTP resources and MCP tools, and it operates close to a huge share of public web traffic. It could validate availability, latency, correct 402 behavior, and other service-quality signals at the network edge. Cloudflare does not currently document a general public x402 Bazaar equivalent to CDP’s, so this is an opportunity rather than a claim about an existing product.

Amazon already gives agents payment controls, wallets, budgets, observability, and access to Coinbase Bazaar through Bedrock AgentCore. It could eventually combine x402 resources with MCP tools, AWS Marketplace products, and APIs deployed on AWS, but its documented Bazaar integration today is Coinbase’s.

Google may be the most important long-term possibility. Google built its business by indexing pages and answering navigation questions. Agentic commerce requires a related index of capabilities: APIs, tools, agents, datasets, and paid content that software can evaluate and purchase. I have not seen Google announce an x402 Bazaar; this is a prediction about where search may evolve, not a description of a current Google product.

What sellers need to publish and monitor

The seller’s job is no longer finished when an endpoint returns a correct 402. Every discoverable resource needs a distribution record that can be rendered into the formats supported by each channel and checked after publication.

1. Describe the capability in natural language using the terms a buyer would search—not only the internal route name.
2. Publish accurate HTTP methods, prices, assets, networks, input schemas, output schemas, and realistic examples.
3. Make unauthenticated discovery probes reach the payment challenge before ordinary request validation returns a 400 error.
4. Generate an OpenAPI contract when the service exposes APIs, even if Bazaar metadata is also present.
5. Complete and confirm the settlement event required by a facilitator-triggered index such as CDP Bazaar.
6. Check that each external index can actually retrieve and search the listing; do not treat “metadata sent” as “listing guaranteed.”
7. Republish when the URL, method, schema, price, network, or availability changes.
8. Provide a removal path and track which third-party indexes may retain cached metadata after unpublishing.

Where Access402 fits

Access402 should not solve fragmentation by creating one more isolated catalog and asking sellers to manage it separately. The better role is a seller-side discovery control plane: describe a protected resource once, generate channel-specific metadata, publish it where compatible buyers search, and monitor the result afterward.

Today, the Access402 WordPress adapter lets a publisher opt a protected rule into x402 v2 Bazaar metadata for CDP discovery. Access402 stores the authoritative resource and publication state, sends the extension through the payment flow, and lets the publisher stop advertising the resource without disabling its payment rule. CDP still controls whether and how the external listing appears after settlement.

The architecture is intentionally provider-based so additional directories can be added without changing every adapter. The longer-term goal is to render one canonical Access402 resource into CDP Bazaar metadata, OpenAPI discovery, Access402’s own directory, MCP-compatible publication, and other marketplaces as they mature.

The discovery layer will determine who gets bought

The x402 payment layer is advancing quickly. Discovery is catching up, and Coinbase is doing the most complete documented work today. But sellers should not have to rebuild distribution every time a new agent platform or Bazaar becomes important.

The winning discovery systems will do more than list endpoints. They will understand capability, compatibility, cost, reliability, freshness, and trust. The winning seller infrastructure will keep resources accurate and visible across those systems without making the seller operate a separate integration for every index.

Making APIs payable is the beginning. Making them findable is how an agent economy becomes a market.

Put this into practice

Continue from the problem to the implementation path that fits your resource.