If you have listed an x402 endpoint on Coinbase Bazaar and it has sat at
processing for hours or days, the cause is almost certainly not your settle
call. Bazaar validates a resource by GETting the resource URL and reading the live
402 response — so anything you send only in the settle payload is invisible to it.
We spent a day stuck there. Below are the three preconditions in the order they bite, and then the part nobody warns you about: indexed listings decay.
The mental model most people start with is "I settle a payment, the facilitator tells
Bazaar, my listing appears." That is half of it. The listing record is created from settle,
but promotion from processing to indexed comes from a crawl of your live
endpoint. Bazaar fetches your resource URL, reads the 402 it gets back, and looks
for the metadata describing what you sell.
If that metadata exists only in your settle payload, every settle returns
{"bazaar": {"status": "processing"}} — forever — and nothing in the response
tells you why.
1. GET must return a 402. Indexers probe with GET. If your paid route is
POST-only, a crawler gets 405 Method Not Allowed and there is nothing to
validate. This bites hardest on session-style endpoints where POST is the only "real" verb —
serve the same challenge on GET without persisting anything.
2. Settlement has to go through the facilitator. If you settle directly against the chain over JSON-RPC, nothing tells Bazaar the payment happened. Facilitator-mediated settlement is what creates and refreshes the listing.
3. The live 402 must carry the Bazaar metadata. This is the one that cost
us the day: extensions.bazaar, plus serviceName and
tags on the resource block, have to be present in the 402 your endpoint actually
serves. Every indexed listing we inspected exposes them there.
{
"x402Version": 2,
"accepts": [ ... ],
"resource": {
"url": "https://your-endpoint.example/your/tool",
"serviceName": "What you sell",
"tags": ["your", "tags"],
"description": "One clear sentence"
},
"extensions": {
"bazaar": { "info": ..., "schema": ... }
}
}
The first two are necessary and not sufficient — we fixed both and stayed stuck. Indexing fired within minutes of the first settle after the third landed.
A custom domain is not required. Plenty of indexed listings run on platform subdomains and proxy hosts. If you are about to buy a domain to fix an indexing problem, don't.
Multi-chain support is not required either — but know how it is read.
Bazaar looks at the x402 accepts array. Payment options you expose elsewhere in
the JSON body are invisible to it, so a listing can be entirely correct and still show as
single-chain.
Being indexed is not a permanent state. Bazaar re-reads your live 402 at settle time, so a listing without recurring paid traffic goes stale and drops out of search results.
We measured it across 22 buyer queries against our own listings:
| date | terms matched | what happened |
|---|---|---|
| Aug 6 | 8 / 22 | after a one-off manual re-index |
| Aug 9 | 5 / 22 | decayed — one endpoint gone entirely |
| Aug 10 | — | a single $0.01 settle |
| Aug 11 | 7 long-tail terms | recovered, wider than before |
The pattern across our three listings: one settle followed by silence meant gone within about three days, while endpoints taking one to three settles a day never decayed at all. That difference is what makes decay the explanation rather than a platform-side change in the same window — in those three days the two endpoints with organic settles stayed indexed while the one without dropped. The drop tracked settle cadence, not the calendar. If your listing has organic paid traffic you will never notice this. If it does not, you are indexed for a few days after each manual re-index and invisible in between — and nothing in the UI tells you which state you are in.
Since early August 2026 there is a second reason a listing can vanish from search, and it
has nothing to do with decay. Bazaar's index has a curated subset, and a curatedOnly
parameter decides whether a query returns everything or only that subset. A provider can be
fully indexed and still return zero results on a client that defaults to curated-only —
indistinguishable, from the outside, from being de-indexed.
Two requests, seconds apart, tell the two apart:
GET .../discovery/search?query=<your brand> GET .../discovery/search?query=<your brand>&curatedOnly=true
Present in the first and absent from the second means you are indexed but not curated. No amount of settling will change that — it is not a decay problem, and paying to "refresh" would be money spent on something payment cannot fix. (We are in exactly that position, and the criteria for curation are an open question in x402-foundation/x402#3136.)
This matters for the keepalive below too: the surface your presence check queries has to be the surface your buyers query. Ours reads the REST endpoint, which still defaults to unfiltered — so it reported us indexed and healthy throughout, while a buyer on a curated-by-default client would have seen nothing at all. Measure what your customer sees, not what is convenient to query.
The naive fix is a scheduled settle. Don't — you would be paying for a re-index you usually don't need, on a cadence you cannot validate. Check first, pay only if absent:
search Bazaar for your brand term (free) ├─ your resource URL present? → done, spend $0.00 └─ absent? → settle one real call, re-index
Ours runs once a day inside a job that already existed. Steady state costs nothing, and the fire rate becomes a free ongoing measurement of the decay rate itself.
Three rules worth copying, each learned by nearly getting it wrong:
Once indexed, the instinct is to widen serviceName and tags to catch broad
queries. We ran that experiment across 22 queries and it does not work: broad head terms went
from 0/9 to 1/9 after renaming all three listings, while precise compound terms matched
reliably. Keyword-stuffed names are also the exact pattern trust scorers penalise. Own the
narrow terms that describe what you actually do.
Measurement footgun, if you build a checker: when a tool is payable on more than one path, the listed URL may not be the canonical one you would guess. Match with path tolerance. An exact-match checker will report that you have been de-indexed while you are sitting in the results — it cost us an afternoon of false alarm.
extensions.bazaar,
serviceName and tags in the live 402.Related: the envelope bug that quietly tanks your trust score — the same class of problem, where the copy of your metadata that machines read is not the one you were watching.
We publish delivery scores for x402 endpoints — settle-and-verify runs, with receipts: