Your x402 Endpoint Isn't in the Bazaar Yet — and It's Probably Not Your Metadata

Every few weeks someone in the x402 channels asks the same thing: "I deployed a valid endpoint, why isn't it in the Bazaar?" The usual first guess is metadata — a missing field, a bad extensions.bazaar block, a truncated description. Sometimes that's right. But the larger answer is structural, and it's written plainly in the CDP docs: the Bazaar has no registration step at all. A resource gets indexed when a payment settles through the CDP Facilitator.

Discoverability is metadata; indexing is settlement. Two different gates. Most sellers only ever test the first one.

Gate one: is your endpoint discoverable?

This part you control directly, and you can check it before you ever take a payment. CDP exposes a free, unauthenticated validation endpoint:

POST https://api.cdp.coinbase.com/platform/v2/x402/validate

It returns bazaarExtension.discoverable plus a list of named preflight[] checks, each with a severity. The rule that matters: a failure with severity == "required" means the resource will never be indexed; advisory is a warning, not a blocker.

We ran a stratified sample of 64 live endpoints from our own catalog (across price and category) through it:

64 / 64 discoverable = true, 0 required preflight failures.

As a negative control we fed it one endpoint we already knew was retired (x402-language-detect): discoverable = false, 21 required failures. The validator is not a rubber stamp — it flips on a genuinely broken resource.

So our metadata is fine. And that is exactly the trap. Passing gate one proves nothing about gate two, and gate two decides whether anyone can find you.

Gate two: has your endpoint settled?

From the CDP seller docs, verbatim:

"Every validated endpoint is eligible for indexing in the CDP Bazaar after a successful settled payment." — with the setup item: "Complete a successful paid call through the CDP Facilitator."

Not after registration. Not after validation. After a settled payment through the CDP Facilitator.

This is the fact that explains the most common confusion. If your 402 is answered and settled by some other facilitator — or by your own gateway, as ours is — then no CDP settlement ever occurs, and by the docs' own rule your resource is eligible forever and indexed never. It is not a metadata problem. It is a rail condition.

On the settlement request, two fields must be present or the route is treated as an ordinary 402 and skipped:

• paymentPayload.extensions.bazaar — the metadata block the index stores.
• paymentPayload.resource — which route it belongs to.

The docs put it flatly: "Only routes that declare Bazaar metadata are indexed."

What gets you removed

Being indexed is not permanent. Three documented exits, none of which announces itself:

The middle row is the one to internalize. An endpoint that starts returning 200 — because you added an unauthenticated demo path, or a refactor bypassed the payment middleware, or a CDN cached a success response — gets delisted for being too available. The index is a directory of things that charge money; when a thing stops charging, it stops being a useful row.

Two edge cases that quietly sink good endpoints

1. TypeScript indexes you by default; Python does not. On the CDP SDK's TypeScript building blocks, discovery is automatic — "You do not need to add a discovery setting." On Python it is explicitly opt-in: you register the Bazaar resource-server extension and declare metadata per route yourself. Same protocol, same 402 shape, opposite default. A Python seller can ship a textbook-correct endpoint and never appear, purely because the language differs.

2. High-cardinality path segments get collapsed. The Bazaar normalizes any path segment that consists entirely of a high-cardinality identifier — a UUID, a wallet address, a tx hash. If your product is /token/<address> or /tx/<hash>, every one of those URLs collapses into a single index entry. Usually the right call for the index, but it means a parameterized API looks like one resource, not thousands. If you need distinct entries, the escape hatch is a prefix or suffix that is not an identifier.

What a seller should actually do

• Validate before you deploy, not after. One unauthenticated call names the exact required fields you're missing.
• Confirm your settlement rail. If being in the CDP Bazaar matters, the payment must settle through the CDP Facilitator. Verify it — nothing in your 402 tells you which facilitator will clear it.
• Send the two fields on the settlement payload — extensions.bazaar and resource. Static metadata alone is not enough.
• Keep answering 402. A convenient unauthenticated path is a delisting vector. If you want a free tier, gate it behind the same signed-trial check so the unauthenticated answer stays a 402.
• Don't read a small index count as a metadata failure. For most of the catalog it's settlement volume, not schema quality. Check both gates before hunting a bug that isn't there.

Sources: CDP x402 seller docs, "Get discovered" (docs.cdp.coinbase.com/x402/seller/get-discovered), read 2026-10-04. Validation sample: POST api.cdp.coinbase.com/platform/v2/x402/validate over 64 live endpoints from our catalog, all discoverable = true with zero severity: "required" failures; negative control on a retired endpoint returned discoverable = false. Quotes attributed to the CDP docs are verbatim.