Skip to main content
Think of it as a search index for payable APIs and MCP tools, enabling the autonomous discovery and consumption of services. The x402 Bazaar is in early development. While our vision is to build the “Google for agentic endpoints,” we’re currently more like “Yahoo search” - functional but evolving. Features and APIs may change as we gather feedback and expand capabilities.

Overview

The Bazaar solves a critical problem in the x402 ecosystem: discoverability. Without it, x402-compatible endpoints and MCP tools are like hidden stalls in a vast market. The Bazaar provides:
  • For Buyers (API Consumers): Programmatically discover available x402-enabled services (HTTP endpoints and MCP tools), understand their capabilities, pricing, and schemas
  • For Sellers (API Providers): Automatic visibility for your x402-enabled services to a global audience of developers and AI agents
  • For AI Agents: Dynamic service discovery without pre-baked integrations - query, find, pay, and use

How It Works

Facilitators that support the Bazaar extension may provide a /discovery/resources endpoint that returns all x402-compatible services registered through the respective facilitator. Services (HTTP endpoints and MCP tools) are discoverable when they include the bazaar extension in their route configuration. Note: The spec for marketplace items is open and part of the x402 scheme, meaning any facilitator can implement their own discovery layer.

Settlement Response Header

After processing a payment that includes the bazaar extension, facilitators may return an EXTENSION-RESPONSES HTTP header to communicate extension-specific outcomes to the client. Header name: EXTENSION-RESPONSES Header value: A base64-encoded JSON object keyed by extension name. The bazaar key contains the bazaar extension’s response: Status values: Example (success):
(base64 of {"bazaar":{"status":"success"}}) Example (rejected):
(base64 of {"bazaar":{"status":"rejected","rejectedReason":"info failed schema validation"}}) Clients that understand the bazaar extension should read the bazaar key of this header to confirm cataloging succeeded and surface any rejection reason for debugging.

Basic Flow

  1. Discovery: Clients query the /discovery/resources endpoint to find available services
  2. Selection: Choose a service based on price, capabilities, and requirements
  3. Execution: Use x402 to pay for and access the selected service
  4. No Manual Setup: No API keys, no account creation, just discover and pay

API Reference

List Endpoint

Retrieve all available x402-compatible endpoints and MCP tools from a facilitator that supports Bazaar discovery:
Note: The recommended way to use this endpoint is through the Bazaar facilitator client extension shown below. Response Schema Each resource in the list contains the following fields:
Resource Types The type field indicates the resource type:
  • "http" - HTTP endpoints (GET, POST, PUT, PATCH, DELETE, HEAD)
  • "mcp" - MCP (Model Context Protocol) tools
For MCP tools, the extensions.bazaar.info.input object will contain:
  • type: "mcp" - Identifies this as an MCP tool
  • toolName - The MCP tool name (used in tools/call requests)
  • inputSchema - JSON Schema for the tool’s arguments (follows MCP Tool.inputSchema format)
  • description - Human-readable description of the tool (optional)
  • transport - MCP transport protocol: "streamable-http" (default) or "sse" (optional)
  • example - Example arguments object (optional)
Note: For MCP tools, the unique resource identifier is the tuple (resource, extensions.bazaar.info.input.toolName) since MCP multiplexes multiple tools over a single server endpoint.

Quickstart for Buyers

Step 1: Discover Available Services

Fetch the list of available x402 services using the facilitator client:

Step 1b: Search for Services

You can also search for services using a natural-language query. Pagination is facilitator-defined: some facilitators may include top-level limit and cursor, and others may omit them.

Step 2: Call a Discovered Service

Once you’ve found a suitable service, use an x402 client to call it:

Step 2 (MCP tools): Call a Discovered MCP Tool

For discovered MCP tools, use the x402 MCP client to call the tool after paying:

Quickstart for Sellers

Listing with Bazaar Extension

Add the bazaar extension to your route configuration to make your API or MCP tools discoverable. Supported Resource Types:
  • HTTP Endpoints - Standard REST APIs (GET, POST, PUT, PATCH, DELETE, HEAD)
  • MCP Tools - Model Context Protocol tools for AI agent integration

Dynamic Routes

The Bazaar extension supports parameterized routes (e.g., /users/[userId], /weather/[country]/[city]). When you use route parameters:
  • The extension automatically extracts concrete parameter values into pathParams (e.g., { "userId": "123" })
  • A routeTemplate field is added using :param syntax (e.g., /users/:userId)
  • Facilitators use routeTemplate as the catalog key, consolidating all requests to the same route pattern into a single discovery entry
This means /users/123, /users/456, and /users/789 all map to the same catalog entry: /users/:userId. Note: Wildcard segments (*) within a path (e.g. /api/*/data) are automatically converted to named parameters (:var1, :var2, etc.) for catalog normalization. However, bare wildcard patterns (e.g. "*" with no literal path segments) do not produce a routeTemplate — use a keyed path pattern in withX402 (e.g. { "/api/weather": config }) so the resource is indexed with the correct URL.

Service Metadata

Resource servers can publish provider-level metadata on the resource object of the 402 response. Facilitators use these fields to enrich Bazaar search results with a human-readable name, topical tags, and an icon — no out-of-band admin step required. All three fields are optional. Servers that omit them produce byte-identical 402 responses; clients that don’t recognize them ignore them. These fields are set directly on your route configuration, alongside description and mimeType:
Validation rules: Facilitators apply soft-drop rules — a field that fails validation is silently discarded while the rest of the metadata is preserved. serviceName and tags are restricted to printable ASCII (U+0020–U+007E) so that string-length checks are consistent across TypeScript, Python, and Go. iconUrl must be an absolute http:// or https:// URL with no IP literals or loopback hostnames (SSRF defense).

Adding Metadata

To enhance your listing with descriptions and schemas, include them when setting up your x402 middleware. You should include descriptions for each parameter to make it clear for agents to call your endpoints:

Adding Metadata for MCP Tools

To make paid MCP tools discoverable, pass the discovery extension in your payment wrapper config:

Troubleshooting catalog visibility

Whether and how a resource appears in a facilitator’s catalog is an implementation detail of the facilitator operator, an external 3rd party service provider. Payment verification and settlement succeeding does not, by itself, guarantee catalog inclusion. If a resource does not appear where you expect, contact the facilitator or catalog operator you are integrating with. Catalog behavior, indexing latency, and discovery APIs are outside the scope of the x402 open-source repository. It is adviced to use the official x402 SDKs (or a maintained third-party SDK) to declare, echo, and validate bazaar data, instead of hand-rolling PaymentRequired, PaymentPayload or extension schemas. Common protocol-level mistakes include:
  1. The settled PaymentPayload did not carry the extension. Cataloging happens when a facilitator processes a PaymentPayload that includes the echoed bazaar extension. A server-side declaration alone catalogs nothing if no paying client echoes it; a settlement whose payload omits the extension catalogs nothing either.
  2. The echoed declaration is not spec-conformant. Servers advertise bazaar data in PaymentRequired (HTTP: PAYMENT-REQUIRED header; MCP: tool-result structuredContent). Clients must echo that data into PaymentPayload. Facilitators validate the payload before cataloging; non-conforming content may be dropped even when verify and settle succeed. Frequent mistakes:
    • missing info.input.type / info.output.type (when output is present)
    • a relative resource.url — use an absolute URL
    • malformed accepts entries (e.g. asset as an object instead of a string, or a missing atomic-units amount)
    • service metadata violating the validation rules above — invalid fields are soft-dropped individually
    • $ref or $id values in the schema field that are not same-document JSON Pointer fragments (i.e. do not start with #) — external references such as https://..., file://..., or relative URIs are rejected to prevent SSRF/LFI (CWE-918). Only in-document references like "$ref": "#/definitions/foo" are allowed.
  3. Treating the absence of EXTENSION-RESPONSES as failure. Facilitators may return this header; its absence carries no signal. When present, bazaar.status and rejectedReason reflect that facilitator’s outcome.
  4. Not allowing for asynchronous cataloging. A "processing" status means the declaration was accepted but indexing may happen later. Allow for delay before concluding failure with your facilitator.
If your facilitator exposes optional discovery endpoints, GET /discovery/resources?payTo=<address> can confirm what that facilitator has cataloged for a given payee. Reference implementations in the x402 repo: Please compare your setup against these before opening a support request with your facilitator.

Support

FAQ

Q: How do I get my service listed? A: Add the bazaar extension to your route configuration. See the examples above. Q: My service settles payments but doesn’t appear in a facilitator’s catalog — why? A: Catalog indexing is a facilitator implementation detail, not something the x402 OSS repo controls. Contact the facilitator or catalog operator you’re using first. For common self-checks, see Troubleshooting catalog visibility above. Q: How can I make endpoint calls more accurate? A: Include descriptions clearly stating what each parameter does and how to call your endpoint, but do so as succinctly as possible. Q: How does pricing work? A: Listing is free. Services set their own prices per API call, paid via x402. Q: What networks are supported? A: Currently Base (eip155:8453), Base Sepolia (eip155:84532), Solana (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp), and Solana Devnet (solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1) with USDC payments. Q: Can I list non-x402 services? A: No, only x402-compatible endpoints can be listed. See our Quickstart for Sellers to make your API x402-compatible. Q: What are MCP tools and how do they work with Bazaar? A: MCP (Model Context Protocol) tools are AI-agent-friendly interfaces that can be discovered and paid for through x402. When listing an MCP tool, use the MCP Bazaar discovery helper and include the tool name (toolName) and input schema. The unique identifier for MCP tools is the combination of the resource URL and tool name, since multiple tools can be served from a single MCP endpoint.