x402 Bazaar: How AI Agents Discover and Pay for Services Autonomously

One of the less-discussed pieces of the x402 ecosystem is the Bazaar—the discovery layer that makes automated service composition possible. Everyone talks about the payment protocol. Not enough people talk about how agents actually find the services they need to pay for.

Without discovery, x402 is still useful: you can hardcode endpoint URLs, configure them in your agent’s tool list, and call them when needed. But that’s not meaningfully different from traditional API integrations. The Bazaar is what makes x402 an ecosystem rather than just a payment standard.

What the Bazaar Actually Is

The Bazaar is a registry and discovery API built into the Coinbase CDP facilitator infrastructure. When a service registers with the Bazaar, it publishes structured metadata about what it does, what it accepts, what it returns, and what it costs. That metadata is queryable programmatically—which means an agent can search for services by capability without any human configuration.

Think of it like a marketplace where the buyers are autonomous software. An agent building a research pipeline can query the Bazaar for “services that convert HTML to PDF” and get back a list of registered endpoints with their schemas, pricing, and performance characteristics. It can then evaluate those options, select the best fit, make a payment, and use the service—all in the same execution.

This is why discovery metadata quality matters as much as the service itself. A service with a complete, accurate schema is discoverable. One with a vague description and no input/output schema is effectively invisible to autonomous buyers.

How Services Register

Registration happens through the payment middleware configuration. Here’s what a fully-specified Bazaar entry looks like:

paymentMiddleware({
  facilitatorUrl: 'https://x402.org/facilitator',
  routes: {
    '/convert/html-to-pdf': {
      price: '$0.01',
      network: 'base-mainnet',
      config: {
        // These fields power Bazaar discovery
        description: 'Convert HTML content or a URL to a PDF document',
        category: 'document-processing',
        tags: ['html', 'pdf', 'conversion', 'document'],
        mimeType: 'application/json',
        inputSchema: {
          type: 'object',
          required: ['html'],
          properties: {
            html: {
              type: 'string',
              description: 'Raw HTML string or URL to convert'
            },
            options: {
              type: 'object',
              properties: {
                format: { type: 'string', enum: ['A4', 'Letter', 'Legal'] },
                margins: { type: 'object' }
              }
            }
          }
        },
        outputSchema: {
          type: 'object',
          properties: {
            pdf: { type: 'string', description: 'Base64-encoded PDF' },
            metadata: {
              type: 'object',
              properties: {
                pages: { type: 'number' },
                fileSize: { type: 'number' },
                processingTime: { type: 'number' }
              }
            }
          }
        }
      }
    }
  }
})

The description, category, tags, and schemas are what power search. An agent querying “document conversion” will match on the category and tags. An agent with a specific workflow requirement can inspect the inputSchema to confirm the service accepts what it needs to send.

Querying the Bazaar

The Bazaar exposes a discovery endpoint through the CDP facilitator. A simple capability search:

const response = await fetch(
  'https://x402.org/facilitator/bazaar/search?q=document+conversion&category=document-processing',
  { headers: { 'Accept': 'application/json' } }
)

const services = await response.json()
// Returns array of registered services with metadata, pricing, and endpoint URLs

An agent can then make an intelligent selection based on:

Pricing (cheapest for commodity operations, willing to pay more for quality)
Response time characteristics (from Bazaar performance metadata)
Schema compatibility (does the service accept the format the agent has?)
Provider reputation (future: ratings and usage statistics)

This composability is where the “AI agent economy” framing becomes concrete rather than speculative. The agent isn’t just paying for services you told it about in advance. It’s discovering, evaluating, and contracting for services dynamically based on its current task.

How PicoPayd Approaches Bazaar Registration

At PicoPayd, every service is registered with what we consider the minimum acceptable metadata:

Accurate, specific description — not “converts files” but “converts HTML or URLs to formatted PDF documents using headless Chrome rendering”
Full input schema with types and constraints — including which fields are required, what enums are available, and meaningful field descriptions
Full output schema — so agents know what they’ll receive without making a test call
Accurate category and tags — matching vocabulary that agent frameworks are likely to search for
Realistic performance characteristics — median response time, not best-case

The last point matters more than it sounds. An agent building a time-sensitive pipeline needs to know if this service responds in 200ms or 2 seconds. Inaccurate performance metadata causes failed agent workflows.

The Discovery Gap Problem

Here’s a tension in the current ecosystem worth understanding. x402 has 10,000+ registered endpoints, but agent discoverability varies dramatically. Services registered with bare-minimum metadata (a description and a price) are technically in the Bazaar but practically undiscoverable by capability-based queries.

This creates a winner-takes-more dynamic: services with excellent metadata get found by autonomous agents and accumulate usage, while services with poor metadata only get calls from humans who already know the endpoint URL.

The practical implication: if you’re building x402 services with the intent of capturing agent-driven traffic, metadata quality isn’t an afterthought. It’s the product.

Beyond the CDP Bazaar

The CDP Bazaar isn’t the only discovery mechanism worth knowing about. A few others have emerged:

x402bazaar.app — Community-built explorer for browsing registered services visually. Useful for humans evaluating the ecosystem; less relevant for agent discovery.

llms.txt files — Some service providers are adding x402 endpoint information to their llms.txt (the emerging standard for telling LLMs what’s available at a domain). This is a complementary discovery mechanism alongside the Bazaar.

OpenAPI with x402 extensions — Services publishing OpenAPI specs can annotate endpoints with x402 pricing information, making them discoverable through OpenAPI registries. Less standardized than the Bazaar but compatible with existing tooling.

The Bazaar is the most mature and purpose-built for agent discovery. The others are supplements.

What Agents Can Do With This Today

The practical question is: which agent frameworks can actually use Bazaar discovery right now?

Direct x402 SDK integrations work cleanly. The TypeScript client handles discovery queries, payment, and retry within its client.fetch() wrapper. You write normal fetch calls; the client handles 402 challenges automatically.

LangChain and similar frameworks work well when you define tools pointing to Bazaar-discovered endpoints. The agent doesn’t do the Bazaar query itself; your orchestration layer does the discovery and passes endpoint URLs to the agent as available tools.

Fully autonomous discovery—where an agent queries the Bazaar mid-task and decides to call a service it’s never been explicitly told about—is technically possible but uncommon in practice. Most production agent pipelines do the discovery at startup or configuration time, not at runtime. That’s not a protocol limitation; it’s that most agent frameworks aren’t architected for fully dynamic tool registration yet. That’s changing.

MCP (Model Context Protocol) integration is the near-term path for fuller autonomy. An MCP server that wraps x402 services can expose them as Claude or GPT tools dynamically, with the Bazaar as the backing registry. PicoPayd is actively exploring this pattern for its service catalog.

The infrastructure for fully autonomous agent commerce is in place. What’s still maturing is the agent-side tooling to use it.

Featured Image Suggestion: Network graph visualization showing AI agents (nodes) connected to service endpoints (other nodes) through the Bazaar discovery layer (central hub). Clean dark background, emerald/indigo color scheme.