How we ship x402 endpoints without confusing discovery with demand

Distribution work gets dishonest when teams collapse five different states into one word: live. An endpoint can be deployed but absent from catalogs, cataloged but not indexed, indexed but never called, or called only by its owner. We use a release ladder that keeps machine discoverability, external demand, settlement, and revenue separate.

Start with one canonical product catalog

Every discovery surface should describe the same routes, prices, identities, and trust boundaries. Hermes Plant generates its public API catalog, OpenAPI document, x402 manifest, buyer-facing pages, and validation inputs from the same product definitions. That makes drift a test failure instead of a marketing inconsistency.

• OpenAPI documents request, response, and 402 challenge shapes.
• The x402 manifest carries route, price, network, asset, and pay-to identity.
• The API catalog and human pages point back to the same canonical routes.
• Agent skills and MCP listings state permissions and trust boundaries without silently authorizing spend.

Validate each distribution channel for what it proves

A successful registry lookup is useful evidence, but it proves only that the registry recognizes a route. It does not prove curation, ranking, indexing, calls, purchases, or repeat buyers. We record the strongest fact each channel can support and stop there.

• Coinbase Bazaar merchant lookup: the route is recognized by the Bazaar interface.
• Coinbase curated state or skill URL: an additional field that must be observed, never inferred from lookup success.
• APINow quote and catalog identity: the integration can resolve the intended Hermes Plant product.
• Agent Skills CLI install: the reviewed static skill artifact can be fetched and installed.
• MCP directory readback: the public listing resolves to the correct remote MCP endpoint.
• Google sitemap and URL inspection: submission and indexing are separate states.

Use a no-spend release gate

Discovery verification should not require buying your own endpoint. Our release workflow checks catalog parity, validates every route with Coinbase, exercises the unpaid 402 challenge, and runs production smoke tests without signing or settling a payment.

release_gate:
  manifest_routes == catalog_routes
  openapi_routes == catalog_routes
  coinbase_validation == pass_for_every_route
  unpaid_request == valid_402_challenge
  owner_funded_settlements == 0
  production_smoke == pass

Keep a strict claim ladder

1. Shipped: code and configuration exist in the deployed release.
2. Discoverable: a public catalog or registry resolves the canonical route.
3. Submitted: a sitemap or directory submission was accepted.
4. Indexed: the target system reports the URL or product as indexed.
5. Externally called: a non-owner client invoked the route.
6. Settled: payment evidence and the commercial ledger reconcile.
7. Repeat demand: an unaffiliated payer returned in a separate buying event.
8. Revenue: settled value is reported with refunds, fees, and owner-funded activity separated.

Set demand gates before expanding the catalog

More routes create maintenance and positioning costs. We do not expand because a dashboard moved or a directory entry appeared. The current catalog-expansion gate requires either 10 verified unaffiliated payers, or 25 paid calls from at least four payers. Paid discovery requires at least three payers and one repeat payer. These are operating rules, not forecasts.

catalog_expansion =
  unaffiliated_payers >= 10
  OR (paid_calls >= 25 AND distinct_payers >= 4)

paid_discovery =
  distinct_payers >= 3
  AND repeat_payers >= 1

The verified July 21, 2026 snapshot

The production release validated all 19 x402 routes with Coinbase and passed the no-spend smoke. The public sitemap contained 193 URLs with no internal parity duplicates, missing expected content, or crawl failures in our direct audit, and Google accepted the sitemap submission.

The same snapshot did not justify stronger claims. Coinbase merchant lookup recognized all 19 routes, but none of the 19 routes was curated and none exposed a skill URL. Google URL inspection did not yet report /agent-services/action-safety or /integrations/apinow as indexed. Those are distribution tasks in progress, not demand or revenue outcomes.

What compounds from here

1. Keep every machine-readable surface in parity as the catalog changes.
2. Submit new high-intent pages through the sitemap and IndexNow, then wait for public indexing evidence.
3. Publish implementation content that links directly to canonical product and skill pages.
4. Track unaffiliated payer count, paid calls, repeat buyers, settlement, and refunds separately.
5. Expand products or paid discovery only when the pre-committed demand gates clear.

This process is slower than declaring victory after a listing appears. It is also how distribution compounds without corrupting the evidence needed to decide what to build, price, or promote next.