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 question: "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 description that got truncated. 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. Those are two different gates, and most sellers only ever test the first one.

Gate one: is your endpoint discoverable?

This is the part you control directly, and it is fully checkable 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 a bazaarExtension.discoverable boolean plus a list of named preflight[] checks, each carrying a severity. The rule that matters for a seller is simple: a failure with severity == "required" means the resource will never be indexed; a failure with severity advisory is a warning, not a blocker.

We ran our own catalog through it — a stratified sample of 64 live endpoints across the price and category range. Result:

That is the honest state of our metadata: fine. And it is exactly the trap. Because passing gate one proves nothing about gate two, and it is gate two that decides whether anyone can find you.

Gate two: has your endpoint settled?

From the CDP documentation for sellers, verbatim:

Read that carefully. Not "after registration." Not "after validation." After a settled payment through the CDP Facilitator. This is the single 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 not a bug. It is a rail condition.

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

• paymentPayload.extensions.bazaar — the metadata block the index will store.
• paymentPayload.resource — which route the metadata belongs to.

The docs put it flatly: "Only routes that declare Bazaar metadata are indexed." So the metadata gate is checked in two places — once statically by the validator, and once at settlement time on the live payload.

What gets you removed (the return path)

Being indexed is not permanent. Three documented ways out, and all three are worth watching because none of them announces itself:

The middle row is the one to internalize. An endpoint that starts returning 200 — because you added an unauthenticated "demo" path, or your payment middleware got bypassed in a refactor, or a CDN cached a success response — will be 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. This is also why an endpoint must be deployed on a public HTTPS URL before it can be validated at all: the index probes it from the outside, repeatedly, and your answer has to be a 402 every time.

Two edge cases that quietly sink good endpoints

1. TypeScript indexes you by default; Python does not

If you build on the CDP SDK's x402 TypeScript building blocks, discovery is on automatically — "You do not need to add a discovery setting." If you're on Python, it is explicitly opt-in: you register the Bazaar resource-server extension and declare metadata for each 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 transaction hash. If your product is /token/<address> or /tx/<hash>, every one of those URLs collapses into a single index entry. That's usually the right call for the index (otherwise a single token-lookup service would flood it), but it means a parameterized API looks like one resource, not thousands — and the metadata you declared for "the route" is what stands for all of them. If you need distinct entries, the documented 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 tells you whether gate one is green, and names the exact required fields you're missing.
• Confirm your settlement rail. If indexing in the CDP Bazaar is a goal, the payment must settle through the CDP Facilitator. Verify that, because 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, put it behind the same signed-trial gate as the paid route, so the unauthenticated answer stays a 402.
• Don't read a small index count as a metadata failure. For most of the catalog it is settlement volume, not schema quality. Check both gates and only then go looking for a bug that isn't there.