Why is my x402 API not showing in Bazaar?

A working paid request does not prove discoverability. Check that the exact declared discovery request reaches a valid 402 challenge, that Bazaar extension metadata survives the client and facilitator path, and that the indexed record is not stale relative to the live resource.

What is EXTENSION-RESPONSES in x402?

EXTENSION-RESPONSES is the facilitator-side extension-response channel used to report results for processed x402 extensions. Python SDK 2.22.0 added optional extension_responses fields to VerifyResponse and SettleResponse and populates them from this header.

Why can I see a successful PAYMENT-RESPONSE but no extension_responses?

They are different channels. In x402 Python 2.22.0, extension_responses is available on facilitator VerifyResponse and SettleResponse, while encode_payment_response_header deliberately excludes that sidechannel from the buyer-facing PAYMENT-RESPONSE header.

Can an x402 payment succeed while Bazaar indexing fails?

Yes. Payment settlement and discovery indexing are separate outcomes. Public x402 issue reports document successful verify and settle flows alongside missing Bazaar records, so another payment is not a reliable indexing diagnostic.

Should I keep paying my own x402 endpoint until it appears in discovery?

No. Run read-only challenge, declaration and facilitator-response checks first. Self-funded settlements can manufacture activity without proving that an independent buyer can discover the resource.

Editorial

x402 sellers · Bazaar troubleshooting

Why your x402 API is not showing in Bazaar

A route can verify, settle and move USDC while still being invisible to discovery. Diagnose the discovery contract separately: the exact unpaid request, the 402 challenge, Bazaar extension metadata, facilitator extension responses and the live indexed record.

zFinia published 12 September 2026 · updated 13 September 2026

September 2026 SDK change: inspect the extension sidechannel

x402 Python SDK 2.22.0, released 4 September 2026, added optional extension_responses fields to both VerifyResponse and SettleResponse. The HTTP facilitator client populates them from the EXTENSION-RESPONSES response header.

The same release makes an important diagnostic distinction explicit: encode_payment_response_header excludes this sidechannel from the buyer-facing PAYMENT-RESPONSE. If you only inspect the final response sent back to a buyer, you can miss the extension-processing evidence that matters for Bazaar troubleshooting.

Go received corresponding EXTENSION-RESPONSES handling in early September. For current SDKs, treat extension results as a separate facilitator diagnostic surface rather than assuming they must be embedded in the ordinary payment receipt.

The failure pattern

x402's normal payment path begins when a protected resource returns 402 Payment Required. Bazaar discovery adds a second job: an indexer or facilitator must be able to reproduce the declared resource request and process the metadata that describes the resource.

Public x402 issue reports have documented successful verification and settlement alongside missing Bazaar records and absent extension-response signals. That means “money moved” and “the resource is discoverable” are not interchangeable verdicts.

Start with the narrower question: can an independent discovery client reproduce the declared unpaid request, receive the intended 402, and observe extension processing on the facilitator path?

A seven-step Bazaar diagnostic

Probe the canonical resource without payment. Use the exact HTTP method and minimum request shape declared for discovery. The request should reach the payment gate and return the intended 402 challenge.
Separate HTTP status from transport failure. A 400, 401, 405 or 500 is different from a timeout, DNS failure or refused connection. Preserve the exact observed state.
Decode the live challenge. Confirm x402 version, network, asset, payee, amount or authorization ceiling, timeout and the resource description before looking at a directory copy.
Replay the Bazaar-declared input. If the discovery declaration describes a POST body or query shape, replay that exact request without payment. A declaration that replays to 400 instead of 402 is not a working discovery contract just because another customer request works.
Inspect verify/settle extension results. On current clients, capture the facilitator response and inspect extension_responses or the raw EXTENSION-RESPONSES header. Do not assume it will appear inside the buyer-facing PAYMENT-RESPONSE.
Validate extension shape and protocol era. Bazaar extension fields are versioned protocol data. Do not invent fields from old examples, and do not treat a v1-compatible settlement as proof that v2 extension metadata was accepted.
Compare live and indexed declarations. If a directory already has a record, compare method, schema, network, asset, payee and current terms with the provider-owned resource. Treat a stale record as stale instead of changing the live API to match it.

Do not look for EXTENSION-RESPONSES in the wrong place

One easy debugging mistake is to collapse three different surfaces into one: facilitator verify/settle responses, HTTP extension-response headers, and the payment receipt returned to the buyer. Current Python behavior deliberately keeps extension responses out of the buyer-facing payment-response encoder.

Surface	Inspect it for	Do not infer
402 challenge	Resource terms and extension declaration.	That Bazaar processed the declaration.
Verify / settle response	Validity, settlement outcome and extension responses.	That the buyer-facing receipt includes the sidechannel.
PAYMENT-RESPONSE	Buyer-facing payment result.	That extension_responses must be embedded there.
Bazaar record	What discovery currently exposes.	That live seller terms still match it.

The cold-probe trap

A real customer request may include all required fields, pass validation and reach the payment gate. A discovery crawler's unpaid request can be intentionally sparse. If authentication, schema validation or method routing executes first, the crawler can receive 400/401/405 while paying customers continue to work.

This asymmetry can survive ordinary production monitoring because the successful paid path never exercises the cold probe. Make the declared discovery request reach the payment gate, then lock that behaviour into a regression test.

Do not use another payment as your first diagnostic

Historical Bazaar reports already show why this is wasteful: sellers observed successful settlements while their resources remained absent from discovery. Repeated self-payments can create activity without identifying which discovery boundary is failing.

Use read-only checks first. If every unpaid check passes and a paid probe is truly required, re-check terms immediately before signing, cap the amount in integer base units, perform at most one bounded test settlement and record it as a test cost — never as customer revenue.

Keep four verdicts separate

Verdict	What it proves	What it does not prove
Payment challenge	The canonical unpaid request reaches a valid 402.	That a directory indexed it.
Extension processing	The facilitator returned extension-response evidence.	That the directory has propagated the record.
Indexed record	A particular discovery surface exposes the resource.	That live terms still match it.
Settlement	A payment was actually settled.	Independent demand or successful discovery.

Fix discovery before distributing harder

Once the canonical resource, declared probe and facilitator extension path are clean, return to distribution. Search each target directory first, submit once, preserve a single canonical identity and measure qualified referrals rather than crawler volume.

Where to list an x402 API →Find x402 APIs →Verify before paying →Inspect zFinia machine access →