x402 sellers · discovery
Where to list an x402 API so agents can discover it
Making an endpoint payable is not the same as making it discoverable. Publish the machine contract you own first, then distribute it through legitimate x402 discovery surfaces without turning directory submission into spam or manufactured demand.
zFinia published 12 September 2026 · updated 20 September 2026 · seller implementation guide
The shortest answer
- 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.
- For CDP Bazaar, declare accurate input/output metadata and run Coinbase's public validator with the exact method and resource before any payment.
- Check how Circle's public x402 marketplace sees the service and use its seller-readiness surface to find discoverability problems.
- Test the origin with x402scan before registering, then register once if the resolved routes are correct.
- Search every target directory before submission. Record pending/live/rejected state and do not resubmit merely to create activity.
- CDP initial indexing requires one successful paid call through its facilitator. Treat that as an eligibility step, not proof of ranking, demand or fulfilment.
- 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.
2. Coinbase Bazaar: protocol-native discovery
Coinbase Bazaar is an x402 discovery surface rather than a conventional marketing directory. The current seller flow has a free preflight and a separate indexing trigger: declare Bazaar metadata, validate the public route, then complete one successful paid call through the CDP Facilitator.
The public validator requires no API key. A successful response has valid: true and simulation.outcome: "accepted". That proves the current route and declaration are acceptable at validation time; it does not index the route by itself.
curl -X POST https://api.cdp.coinbase.com/platform/v2/x402/validate \
-H "Content-Type: application/json" \
-d '{"resource":"https://api.example.com/report","method":"POST"}'After the paid-call trigger, cataloging can be asynchronous and ranking is a later calculation based on real usage and listing quality. Inspect EXTENSION-RESPONSES for success, processing or a rejection reason. Do not repeat self-funded calls to imitate demand or repair invalid metadata.
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.
A duplicate-safe listing workflow
| Stage | Evidence | Rule |
|---|---|---|
| Own | OpenAPI + live 402 + canonical URLs | Fix your origin before distribution. |
| Search | Origin/domain/endpoint query | Do not create a second record if one already exists. |
| Submit | One authorized registration or protocol-native discovery path | Disclose affiliation where a human-maintained directory is involved. |
| Record | Pending / live / rejected / blocked | Do not resubmit while a maintainer or indexer is acting. |
| Verify | Directory record + live endpoint | Live terms beat stale directory copy. |
| Measure | Qualified referrals, API inspections, repeat use, paid conversion | Do not count crawler probes or your own checks as demand. |
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.
Build discovery and verification as one funnel
Sellers want to be found; buyers want to avoid stale or unsafe listings. The strongest x402 acquisition loop satisfies both. Publish machine-readable truth, distribute it once, and make it easy for the buyer to verify the resource before payment.
Sources
- Coinbase Developer Platform — current validation, indexing and ranking checklist
- 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