# Listing 14 paid endpoints in the x402 Bazaar: what actually decides it

Notes from listing 14 paid HTTP endpoints in the PayAI Bazaar discovery index on 2026-10-30,
with the settlement receipts that prove each step. Every number here is re-checkable against
`https://facilitator.payai.network/discovery/resources` and `/discovery/search`.

## Result

14 of 14 endpoints are in the index with complete metadata. Ten search terms were run against
`/discovery/search`; the endpoints landed in the first two results for `red team scan`,
`llm security`, `x402 benchmark`, `erc20 transfer history`, and `transaction receipt`.

## The failure that cost the most

Settlement returned 200 and `paid: true` for 308 calls over several weeks, and not one of those
calls produced a listing. The reason was not the settlement: it was the `resource` field sent to
the facilitator.

Our code chose the catalog key from a hard-coded whitelist of three paths and fell back to
`/pro/402` for everything else. Twenty endpoints therefore reported themselves as `/pro/402`
on every settlement. Two consequences, both silent:

- those twenty endpoints could never create their own listing, because a listing is keyed by `resource`;
- every settlement of a cheap endpoint rewrote the price on the `/pro/402` listing.

Measured: a `readclean` settlement of $0.000978 wrote `resource: .../pro/402` into the
receipt. The `/pro/402` listing is a $3 product. One cheap test purchase moved its advertised
price by three orders of magnitude.

## What the receipt does and does not tell you

The facilitator reports the listing outcome in a response header, base64 JSON under
`EXTENSION-RESPONSES`, shaped `{"bazaar":{"status":"success|processing|rejected",
"rejectedReason":"..."}}`. Two traps:

1. `processing` is not `success`. It means accepted for async indexing. Only the index itself
   proves the listing exists.
2. The header is written by the seller's server and is not forwarded to the buyer. A client-side
   tool reading it gets `null` and concludes nothing happened, while the listing may be live.

Check the index, not the receipt.

## Rate limiting looks exactly like a bad domain

Seven settlements sent seven seconds apart were all rejected with
`resource_host_ephemeral`. The domain had not changed and one settlement of the same endpoint a
minute earlier had been accepted.

Thirty seconds apart, all seven were accepted. If you batch listings, space them; a burst is
indistinguishable from a wrong host in the receipt.

## Two endpoints that look like one

`/discovery/resources` takes `limit` and `offset`. It silently ignores `q`, `search`, `tags` and
`serviceName`, returning the same page every time. `/discovery/search?query=` is the actual
search.

Testing discovery against `/discovery/resources?q=markdown` returns a page of unrelated listings
and looks like a ranking failure. It is a parameter that does not exist.

## Metadata has to be in the v2 envelope

`serviceName`, `tags`, `iconUrl` and `description` are read from the resource object the client
sends in a v2 payment payload, not from the server's requirements. A v1 payload produces a listing
with all four fields null: present in the index, invisible to every search.

## What is still missing

Being listed is not being chosen. The endpoints above are in the index and rank first or second
for their terms, and the paid settlement count attributed to them in the last 24 hours is 1 for
`readclean` and 1 for `llm-security`. That count includes our own test settlements.

The index is a time-ordered feed of new listings, not a storefront. A listing buys a few hours near
the top and then falls behind every new entry. This report is about the mechanics of getting listed
correctly; it is not evidence that listing produces buyers.

If you run x402 endpoints and want the same check against yours, the interop audit is free for one
endpoint: `POST https://qdmbzzwftor2rgmxupyyasguhy.srv.us/agent-scan` with `{"spec": ...}`.