x402 Bazaar, x402scan, marketplaces: why get listed

Mostly findability. A listing puts a paid endpoint where agents, and the people who build them, go looking, and that is the condition for any sale; on its own it brings few buyers. Over about a month we listed four live x402 services of ours in the x402 Bazaar, in x402scan, in an x402 marketplace or two and in MCP server directories. The gain we had not planned for was in our own code: each catalog reads an endpoint with a parser we did not write, and getting accepted forced fixes to defects our tests had passed for weeks.

Method

From September to 25 October 2026 we put the four services wherever a paying agent or its builder might start: the Coinbase x402 Bazaar, x402scan, agent search engines, A2A registries, x402 marketplaces and MCP directories. For each place we noted what it reads (a settled payment, an OpenAPI document, an agent card, a form), whether it took us, and what it complained about. In all we checked 93 places by hand and by script. Of those, 50 were free and working when we checked them, 15 copy their entries from a bigger registry, which leaves nothing to submit, 8 charge for a listing (we did not pay, so we did not test them), 2 list you only if you link back, and 18 we would skip: dead, broken, or a middleman that keeps a cut.

To see what a listing is worth in buyers, we read the entire Bazaar catalog through its public discovery API on 25 October 2026 and took the per-resource counts that the catalog itself publishes: purchases and distinct payers over the last 30 days.

Results

Each catalog reads a different file

The Bazaar has no form. A resource enters it after a payment for that resource settles through the Coinbase facilitator; ours showed up within about fifteen minutes of the first one, and a resource with no settlement for about 30 days drops out again. x402scan ignores the payment and reads only the OpenAPI document served from the domain's root path. When it re-crawled our main API on 25 October, it registered 150 paid resources and failed none. Other places read an A2A agent card, an llms.txt or the x402 file under /.well-known/, and a typical MCP server directory reads a form that a person fills in. A service that lives only on its own website does not exist for an agent that starts from one of these.

Being seen is a chance, not a sale

On 25 October the Bazaar held 58992 entries. Over the previous 30 days the median resource had exactly one distinct payer, and since a resource enters the catalog only after a settled payment, that one payer can be the seller keeping its own entry alive. Roughly one resource in three (34.7 %) had two payers or more, 434 of them (0.7 %) had ten or more, and the ten busiest addresses took 48.5 % of all purchases in the catalog.

So a listing puts you on a shelf beside tens of thousands of others. Whether anyone buys depends on whether agents already need what you sell, and no listing changes that. What it does change is who can find you at all: an agent that searches the catalog can reach your service, and one that searches it while you are absent cannot.

Our code got better while we listed

Every defect below had passed our own tests. Each one surfaced only because a catalog read the endpoint and refused it, scored it low, or showed it without a price.

• An empty catalog block. extensions.bazaar: {} parses, then fails validation: the extension specification wants an info object describing the input and a schema that checks it. Nothing reports the failure; the resource simply never appears.
• A string where an object belonged. We wrote protocols: ["x402"] in the OpenAPI payment block. The indexer behind x402scan expects [{ "x402": {} }], and the string made it throw away the whole block, price included.
• An auth scheme with the usual name. The same indexer decides whether a route needs a key by the scheme's name before its type, so a standard bearerAuth went unrecognised. The scanner then tried the route without a token, got a 401 instead of a 402, and marked it failed. Renaming the scheme to apiKey and keeping type: http, scheme: bearer fixed the listing without breaking real clients.
• A 404 at the advertised address. One registry probes the base URL a service gives it. Ours answered GET /v1 with 404; the registry still counted us alive that day, but nothing obliged it to. Two more of our four services had the same hole. The base path now answers 200 with a short JSON pointer to the catalog and the OpenAPI document.
• A 404 for the wrong method. Our paid file routes answered POST with 404. Within 48 hours five registries and monitors had probed them with POST and recorded "no such resource". Those routes now answer 405 with an Allow header and the same payment requirements.
• An agent card pointing at a web page. An A2A registry gave us 45 out of 100. The url in our card led to a 404 instead of an agent, which cost 25 points, and the card had no supportedInterfaces, which cost 10. The card's address now leads to a live A2A endpoint.
• A document too big to read. An agent search engine did not count our OpenAPI file at all while it weighed 585 KB. A compact 55 KB copy at the same path was counted, and all four services then scored 100 there.
• Tools without hints. MCP directories expect annotations on every tool, and a missing hint is read as the worst case, destructive and open-world. We wrote down which hints the two big directories check and what models set wrong.
• Records without names. One index imported our Bazaar entries with no name and a price of zero. We sent names, descriptions and prices for all 156 records, and none failed.

None of these is exotic, and most of them would have stayed hidden: an agent that cannot read you does not write to complain, it moves on to the next seller. Several of them also explain the quiet ways a resource never reaches the Bazaar.

Validators are free testing with someone else's parser

The Bazaar validator is public, needs no key and registers nothing. On 25 October it accepted both new paid addresses of ours. A check like that is only worth something next to controls: an address of ours that does not exist was rejected, as it must be, and so was the first listed resource of another seller that we tried. That second control is a finding in itself, because being in an x402 catalog says nothing about whether an endpoint still passes today. The next foreign resource we tried was accepted. A parser you did not write carries none of your assumptions, which is exactly why its "accepted" carries more weight than your own green tests.

The catalog shows what others sell

The discovery API returns, for every listed resource, its purchases, its distinct payers and the time of its last call over 30 days, with no key (Bazaar documentation). Before you build a paid tool you can see whether anything like it has paying users, and how many of them there are. We read that before choosing what to build, and we read it again for this post.

What the listings do outside the catalogs

The files the catalogs asked for, an OpenAPI document, an agent card, an llms.txt and a well-known x402 file, are plain machine-readable descriptions of the service, and they serve any crawler that comes by, not only the catalog that asked. Most catalog pages also link to the service. We did not measure either effect, so we list them as reasons, not results.

If you want a second reader for your own listing before a catalog reads it, our listing review is a checklist built from the defects above; the list stands without it. We keep the 93 places, sorted into the five groups from the method, as a free list of places to submit to.

What we did not measure

• Which catalog brought which buyer. An x402 payment carries no referrer, so we cannot credit a sale to a listing. Everything above about findability is about being readable, not about revenue.
• Whether a buyer is a customer. Four purchases on 25 October came from three wallets run by one operator; each wallet had made about 646 outgoing payments to about 110 recipients since the previous evening. Earlier, a low-priced pack on another service of ours had exactly two buyers from outside, and they had paid 212 and 490 different recipients within hours. Those are crawlers that buy, not people who need the service, and an alert that calls them customers misleads.
• The size of the sample. Four services, one network, about one month. Catalogs change their parsers without notice, and every score quoted here is one catalog's own formula on one day.
• The upkeep. A Bazaar entry lapses once its own resource has gone about 30 days unpaid, so each listed resource needs a sale, or a purchase from yourself, every month. We do not know how strictly that is enforced; it is what we observed, not a documented rule.
• Search and links. We did not measure whether the listings changed our rankings in web search or in model-based search, or how many visitors came through catalog links.