x402 Marketplaces: How Listing and Discovery Actually Work
An x402 marketplace is a searchable catalog of paid endpoints that agents can call and pay without signing up. In the reference design, a seller describes its endpoint with the bazaar extension in its 402 response, and a facilitator catalogs it when it processes a payment. Coinbase runs one through its CDP facilitator, and Agentic.Market launched as an x402 storefront in April 2026 through Coinbase's developer platform.
Two layers: a discovery protocol and the storefronts on top
"x402 marketplace" gets used for two different things.
The discovery layer. The x402 v2 specification includes a Discovery API, GET /discovery/resources and GET /discovery/search, and calls the resulting catalogs "Bazaars." The bazaar extension defines how a seller describes an endpoint so a facilitator can index it. Any facilitator can implement this; the spec leaves storage and indexing to the implementer.
Storefronts. Products built for people and agents to browse. The most prominent is Coinbase's Agentic.Market, launched April 20, 2026. The Block reported that it groups services into seven categories (Inference, Data, Media, Search, Social, Infrastructure and Trading) and that providers can join permissionlessly. Coinbase also runs its own Bazaar catalog through its facilitator, the CDP Facilitator.
This page is about the mechanics: how an entry gets created and how an agent queries it. How an agent should choose among results is a separate problem.
How a listing gets created
A seller does not submit a form. The listing is a side effect of serving a paid request.
Declare the endpoint in the 402. The resource server adds a bazaar entry to the extensions object of its PAYMENT-REQUIRED response. It has two parts: info, describing the input (an HTTP method with query parameters or a body, or an MCP tool name with an input schema) and the output (a type and an example), and schema, a JSON Schema (draft 2020-12) that validates info. External $ref values are not allowed.
Add service metadata. Optional fields on the resource object give the catalog a serviceName (printable ASCII, at most 32 characters), up to five tags, and an iconUrl. Facilitators drop any field that fails validation rather than rejecting the listing.
The buyer echoes it. The client copies the extension into its payment payload. The spec states that if the extension is omitted, cataloging will not occur.
The facilitator validates and catalogs. It checks info against schema, extracts the discovery data, and tells the seller's server the outcome in an EXTENSION-RESPONSES header: success, processing (cataloging asynchronously) or rejected with a reason. Buyers never see that header.
Dynamic routes collapse to one entry. A route like /users/[userId] is sent with a routeTemplate of /users/:userId, so every concrete request maps to a single catalog entry.
Listing follows payment
In Coinbase's implementation, a validated endpoint becomes eligible for indexing in the CDP Bazaar only after a successful settled payment through the CDP Facilitator. Coinbase offers a validator, POST https://api.cdp.coinbase.com/platform/v2/x402/validate, that checks the route is reachable, returns a 402, and carries a valid bazaar block. Its docs note that passing does not guarantee a listing, because the validator does not evaluate metadata against Coinbase's content policy. In practice, an endpoint nobody has paid yet is not in the catalog.
How an agent queries a catalog
The list endpoint filters by resource type, payTo address, scheme, network and extension, with offset pagination. The search endpoint takes a natural-language query plus the same filters, an advisory cursor, and may flag partialResults when matches were truncated. Each result carries the resource URL and its full accepts array, so price, asset and network come back with the listing.
Coinbase documents several specifics for its catalog. Discovery is public and needs no CDP API key. Search returns at most 20 resources, ranked by a blend of query relevance and quality. Quality considers recent call volume and unique payers, reported per result over the last 30 days with a last-called time, and also the completeness of the description, output schema and service metadata. The same catalog is reachable through the CDP SDK, a REST API and an MCP server, so an agent can search with tool calls.
What a marketplace does not verify
Descriptions are self-declared. The info block and metadata are written by the seller. The facilitator validates their shape, not their truth.
Popularity can be manufactured. Ranking on call volume and unique payers rewards real demand, but nothing in the mechanism distinguishes real demand from a seller paying its own endpoint from several wallets. A seller paying its own endpoint from several wallets produces real settlements. Treat quality scores as a signal to investigate, not a verdict.
Catalog prices go stale. The listing shows the accepts array from when it was indexed. The 402 the agent receives at call time is the authoritative price, and that is what it must check before signing.
Safety is not endorsement. The spec's sanitization rules, such as rejecting icon URLs that point at IP literals or localhost, exist to stop catalog poisoning. They protect the catalog, not the buyer's money.
Practical checklists
For sellers: key route configuration by the exact path pattern the server serves, so the catalog indexes the right path; include a realistic output example; fill serviceName and tags; run the validator; settle at least one payment through the facilitator whose catalog you want; then confirm the EXTENSION-RESPONSES status.
For buyers: search the catalog, then apply your own policy before paying: a price ceiling per call, an allowlist or a short trial budget for new providers, and a fresh check of the live 402 against what the listing promised. CryptoCadet enforces the money side of that policy structurally: the agent pays from a non-custodial, session-key bounded USDC float on Base, so a bad pick from a marketplace costs at most what the float allows.
Frequently asked questions
- Is the x402 Bazaar the same as Agentic.Market?
- No. The Bazaar is the discovery mechanism defined by x402's `bazaar` extension and Discovery API, which any facilitator can implement, and Coinbase runs one through its CDP Facilitator. Agentic.Market is an x402 storefront launched in April 2026 through Coinbase's developer platform, with seven service categories that providers can join permissionlessly. Launch coverage did not spell out how the two share data, so check each directly.
- How do I get my API listed in an x402 marketplace?
- Declare the endpoint with the `bazaar` extension in your 402 response, including an input description, an output example and a JSON Schema, then serve a paid request through a facilitator that catalogs. For Coinbase's catalog, an endpoint becomes eligible after a successful settled payment through the CDP Facilitator, and its validator checks readiness first.
- Do agents need an API key to search the x402 Bazaar?
- Not for Coinbase's catalog. Its documentation states that Bazaar discovery is public and does not require a CDP API key. Agents can search through the CDP SDK, a REST API or an MCP server. Paying for a listed resource is separate and needs a wallet that can sign the payment the resource's 402 asks for.
- How does the Bazaar rank search results?
- Coinbase says search returns at most 20 resources, ranked by a blend of query relevance and quality. Quality considers recent call volume and unique payers over the last 30 days, plus how complete the description, output schema and service metadata are. Because volume can be self-generated, ranking is a starting point for selection, not proof of reliability.