Three paid x402 experiments, zero Bazaar listings: what discovery actually requires

If you sell an API over x402, the Bazaar is the catalog you want to be in: it is where a paying agent goes to find an endpoint it has never heard of. The common understanding when I built my integration was that a listing follows from your first settled payment. For my endpoint, on the v1 protocol, it did not, three times in a row. This post is the measurements, in order, so the next seller does not have to pay for them.

The setup

My marketplace charges for a few metered API routes. A caller with no account and no key gets a 402 Payment Required whose body is an x402 offer: three price tiers in USDC on Base. Pay one, and the response carries both the data and an API key. The rail went live on production in early August 2026 and has served every keyless caller that 402 since.

Three payments, three configurations

Each experiment was a real mainnet settlement from a wallet I control to my own receiving address, so the actual cost was gas. Each changed exactly one thing.

Each check was a full sweep of the public catalog, about 14,600 entries at the time. The documentation mentions up to ten minutes of caching, and a cached page would look exactly like a real negative, so the third sweep used a unique cache-buster per request and a fresh connection per page. The responses carried no cache headers at all. Zero hits, 3.7 hours after settling, against a stated ceiling of ten minutes.

What was not the trigger

Two plausible fixes turned out to be ruled out by the catalog itself rather than by my own failures.

The discoverable flag. Of roughly 28,700 listed payment options at the time, only 1,905 (6.6%) carried an outputSchema at all, and 1,553 (5.4%) carried discoverable: true. About 94% of the catalog got in without the member I had just added, so it cannot be the precondition.

paymentPayload.resource. The documentation says the settle request must carry it for the catalog to associate discovery metadata with a resource. My payer never sent it; adding it in experiment 3 changed nothing.

The documentation marked v1's outputSchema as deprecated in favour of v2's extensions.bazaar, without saying whether v1 indexing still ran. The three payments were the only way to find out, and the answer, for my endpoint, was no.

What worked

Migrating to x402 v2. I did it as a dual-serve: every 402 still carries the v1 body byte-for-byte, so no existing payer broke, and the v2 offer rides beside it in the PAYMENT-REQUIRED header, with CAIP-2 network names (eip155:8453 rather than base) and a declared extensions.bazaar block. Before paying anything, I ran the offer through the catalog's own validation until it passed every check, with the remaining step described as the endpoint's first verify-and-settle.

One paid seed on 2026-09-06, and a full sweep of 15,649 catalog resources returned exactly one entry for my endpoint: x402Version: 2, with a lastUpdated timestamp equal to the settlement to the second. I checked again on 2026-09-20, two weeks later: 150 pages, 14,973 resources, still exactly one entry for my endpoint, still x402Version: 2. Its lastUpdated has not moved from the seed.

Two traps in checking

The catalog paginates by offset, and it ignores a filter on the receiving address. A query that looks filtered returns the first page of everything, and a first-page check reads as "not listed" when you are on page twelve. Sweep every page and search the whole response.

The catalog changes size while you watch. Between my sweeps it went 14,615, 14,679, 14,601, 14,621. That is not instability, and the next section is why.

The clause that matters most

The documentation also says that resources which have been called at least once but have had no activity in the last 30 days are excluded from results. So a listing is not a door you open once. It is kept by recurring paid traffic, which means the catalog rewards endpoints that are already being paid and quietly retires the ones that are not.

That changes what the Bazaar is for. I had treated it as the thing that would start the loop: get listed, get found, get paid. By its own rules it is closer to the thing that keeps a loop going once it exists. My listing's last activity is still the seed payment of 2026-09-06 - I re-checked on 2026-09-20 and it had not moved - so if no agent pays that endpoint before early October, I expect it to age out, and I will know within one sweep.

Worth stating plainly, because it is the part that surprised me: ordinary traffic does not count. I made a pile of keyless calls to that endpoint on 2026-09-20, each one correctly answered with a 402 and an offer, and lastUpdated did not move by a second. "Activity" here means a settlement the facilitator observed through the protocol, not a request. An endpoint can be busy and still age out of the catalog.

What I would tell another seller

1. Serve v2. If you have v1 payers, serve both from one response; the v1 body can stay byte-identical. 2. Validate the offer against the catalog's own checks before you pay anything. 3. Seed with one real settlement and verify with a full offset sweep, not a first-page query. 4. Do not count on the listing to bring your first customer. Count on it to help keep the customers you have. 5. Keep a discovery surface that belongs to you. My own /.well-known/x402 manifest was fetched by a crawler one second after the first seed payment, and it did not need anyone's indexer to exist.