x402 seller operations

How to get your x402 endpoint listed in Coinbase Bazaar (and stay listed)

Published October 26, 2026 · SpendPreflight · AI-assisted, checked against the official sources linked below.

Getting a paid route into a catalog requires more than returning HTTP 402. Treat payment compatibility, discovery metadata and catalog policy as separate checks. This guide follows the official sources as checked on October 26, 2026; catalog behavior can change.

1. Start with a predictable public route

Choose an HTTPS URL that a buyer can reach without a browser session. Write down its method, required inputs, output and failure behavior. Begin with the official seller quickstart for your framework. Keep testnet and production configuration separate, and compare your actual facilitator’s supported schemes, networks and assets before deploying. A chain name in a README is insufficient evidence of support.

For an initial observation of your own GET route, inspect the unpaid response locally:

curl --include --max-time 15 https://api.example.com/report

Replace the example URL with your endpoint. Stop at the challenge; this command does not sign or settle a payment. If your service needs POST inputs, an unpaid GET may be inconclusive. Do not treat that as proof that the paid operation is broken.

2. Declare discovery data with the SDK

Use the Bazaar extension helpers for the version you deploy. Describe the resource as data: what it does, the input shape and an example of the output. Check the schema against the example you actually serve. Keep the canonical resource URL absolute, and use the documented route-template mechanism for dynamic paths rather than advertising a new listing for every identifier.

The Bazaar integration guide explains that the client must echo the discovery extension into its payment payload. Advertising metadata in the server’s challenge alone does not establish discovery. Check the client integration as well as the server middleware.

3. Follow Coinbase’s catalog process

Coinbase’s seller guide calls for a public HTTPS endpoint, technical validation, usable schemas and examples, compliant metadata, and a successful settled call through the CDP Facilitator. Its validation result does not certify metadata-policy acceptance. Carry the resource and Bazaar extension in the payment payload used for discovery.

If your facilitator supplies an EXTENSION-RESPONSES header, inspect its decoded Bazaar status and rejection detail. Processing can be asynchronous. The generic protocol makes this header optional, so its absence alone is not a failure signal. Successful payment verification or settlement also does not guarantee inclusion in every catalog.

This guide performs no payment for you. Any end-to-end paid check needs your own explicit budget and a compatible payment client.

4. Keep descriptions useful to an agent

Explain the operation and its inputs without directing the buyer’s agent to override its instructions, execute unrelated commands or disclose secrets. Review nested descriptions and examples too. Relevant documentation and JSON Schema links can be legitimate; a URL alone is not evidence of injection.

Coinbase screens discovery metadata before and after indexing. Its content policy describes revising rejected text, redeploying and making another settled call through CDP to trigger discovery again. This is a catalog decision, not a certification offered by SpendPreflight.

5. Check the deployed challenge in CI

Free x402 Lint provides an unpaid snapshot of challenge and metadata observations. Read every warning in context. Its score is heuristic, and an inconclusive report is neither a safety pass nor proof of a failed seller.

Add the free x402 Lint GitHub Action to your workflow to catch observable changes after deployment. It uses shared free quotas and respects robots and host pacing. It does not prove settlement, paid output quality, policy acceptance or continued catalog inclusion.

6. Investigate changes without inventing a cause

Save a dated baseline of the public challenge and the catalog’s explicit status. Compare the deployed URL, method, extension, schema and facilitator configuration when something changes. A missing search result can reflect indexing delay or incomplete observation. Distinguish featured placement, general indexing and an explicit removal status.

The Bazaar Delisting Tracker shows dated aggregate observations. Its partial samples cannot explain a particular seller’s absence. For a catalog-specific rejection, use the operator’s documented support route with a concise, redacted example.

Official references

• Seller quickstart
• Bazaar integration and visibility troubleshooting
• Bazaar extension specification
• Coinbase: get discovered and metadata policy

Protocol references are pinned to commit be54b7d. SpendPreflight operates the linked tools. These checks are informational and do not guarantee listing, security or successful paid delivery.