Where to list an x402 API so agents can discover it

The shortest answer

1. Make the canonical API origin machine-readable: document payable routes, methods, inputs and outputs in OpenAPI and return a correct live HTTP 402 challenge from each paid resource.
2. If you use Coinbase-compatible Bazaar discovery, declare the correct x402 discovery metadata and make sure it survives the buyer/facilitator path.
3. Check how Circle's public x402 marketplace sees the service and use its seller-readiness surface to find discoverability problems.
4. Test the origin with x402scan before registering, then register once if the resolved routes are correct.
5. Search every target directory before submission. Record pending/live/rejected state and do not resubmit merely to create activity.
6. After indexing, re-check the provider-owned endpoint. The live payment challenge wins over stale directory copy.

1. Publish provider-owned truth first

A directory is a discovery convenience. It should not become the only place an agent can learn what your API does or how much it costs. Keep the canonical origin independently understandable so a buyer can verify the listing before spending.

• Expose an OpenAPI document that names the paid routes and HTTP methods.
• Describe inputs and outputs well enough for an agent to call without guessing.
• Return the intended unpaid 402 response directly from the canonical resource.
• Keep price, network, payment asset and recipient verifiable at the live endpoint.
• Use stable canonical URLs; avoid making discovery depend on redirects or hidden signup flows.
• Publish machine-readable service metadata that can be re-crawled when terms change.

The x402 v2 specification includes a discovery API so marketplaces, or “Bazaars,” can expose discoverable resources. That discovery layer is useful, but it sits beside the actual payment contract rather than replacing it.

Read the x402 v2 discovery specification →

2. Coinbase Bazaar: protocol-native discovery

Coinbase Bazaar is an x402 discovery surface rather than a conventional marketing directory. For x402 v2, discovery metadata is carried with the Bazaar extension. Recent Coinbase/x402 contributor guidance is important for sellers: the client-side payment payload must retain the resource and Bazaar extension data that the facilitator uses for discovery processing.

That creates a critical accounting boundary: a successful settlement is not the same event as successful indexing. If a service can accept payment but does not appear in discovery, inspect the metadata handoff and canonical resource behaviour instead of manufacturing extra payments to make the service look active.

3. Circle: searchability is becoming a seller requirement

Circle opened a public, keyless x402 Discovery API on 9 September 2026. Buyers can search services without an API key, Circle account or prior integration and can filter the catalog by attributes such as category, chain and price. Circle's seller surface now frames an API endpoint as a storefront and gives operators an agent-readiness check before they try to earn from machine buyers.

For acquisition, the implication is straightforward: descriptions and schemas now affect whether an autonomous buyer can select the service at all. “We support x402” is weaker metadata than a precise buyer outcome, callable schema, current price and explicit output contract.

4. x402scan: test first, register second

x402scan exposes an explicit “Add your API” flow. Its current discovery quickstart lets a seller test an origin before registration, resolves payable routes, and tells coding agents to stop for review before publishing the listing. That is the right operational order: inspect what will be made public, correct the origin, then register once.

• Search x402scan for the origin and endpoint before creating a new registration.
• Run its discovery test and confirm every resolved route actually belongs to you.
• Check methods, schemas and payment metadata before approving publication.
• Register once; do not create multiple entries because indexing is not immediate.
• After registration, verify the public record against the provider-owned contract.

5. Independent indexes are useful — but they are not protocol truth

The x402 directory layer is fragmenting quickly. Independent indexes can add health checks, payment validation, cross-marketplace aggregation or category search that a protocol-native Bazaar does not provide. That is useful to both buyers and sellers, but each index has its own ingestion rules and methodology.

Treat “indexed,” “verified,” “healthy” and “ranked” as publisher-specific labels. Before paying for placement or changing your API to satisfy one directory, determine whether that surface brings qualified machine buyers and whether its verification actually measures the failure mode you care about.

402 Index, for example, states that it independently health-checks services and separates indexed endpoints from payment-verified endpoints. That is a useful signal, but it still does not override the seller's live payment challenge.

402 Index methodology →

A duplicate-safe listing workflow

What not to do

• Do not submit the same service repeatedly because review is slow.
• Do not create alternate identities to route around a blocked submission path.
• Do not self-buy or generate synthetic calls to make the endpoint look popular.
• Do not copy a directory's stale price or payee into your canonical docs.
• Do not buy paid placement unless the expected qualified acquisition value justifies it.
• Do not describe indexing, crawler traffic or an unpaid 402 probe as customer demand.

Sources

• x402 Foundation — x402 specification v2, Discovery API
• Coinbase — Introducing x402 Bazaar
• Circle — Discover the Whole Agent Marketplace in One Call, 9 September 2026
• Circle for Agents — seller readiness
• x402scan — discovery quickstart
• x402scan — Add your API
• 402 Index — methodology and indexing model