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 thebazaar 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):
{"bazaar":{"status":"success"}})
Example (rejected):
{"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
- Discovery: Clients query the
/discovery/resourcesendpoint to find available services - Selection: Choose a service based on price, capabilities, and requirements
- Execution: Use x402 to pay for and access the selected service
- 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:type field indicates the resource type:
"http"- HTTP endpoints (GET, POST, PUT, PATCH, DELETE, HEAD)"mcp"- MCP (Model Context Protocol) tools
extensions.bazaar.info.input object will contain:
type: "mcp"- Identifies this as an MCP tooltoolName- The MCP tool name (used intools/callrequests)inputSchema- JSON Schema for the tool’s arguments (follows MCPTool.inputSchemaformat)description- Human-readable description of the tool (optional)transport- MCP transport protocol:"streamable-http"(default) or"sse"(optional)example- Example arguments object (optional)
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:- TypeScript
- Go
- Python
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-levellimit and cursor, and others may omit them.
- TypeScript
- Go
- Python
Step 2: Call a Discovered Service
Once you’ve found a suitable service, use an x402 client to call it:- TypeScript
- Python
Step 2 (MCP tools): Call a Discovered MCP Tool
For discovered MCP tools, use the x402 MCP client to call the tool after paying:- TypeScript
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
routeTemplatefield is added using:paramsyntax (e.g.,/users/:userId) - Facilitators use
routeTemplateas the catalog key, consolidating all requests to the same route pattern into a single discovery entry
/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 theresource 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:
- TypeScript
- Python
- Go
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:- TypeScript
- Python
- Go
Adding Metadata for MCP Tools
To make paid MCP tools discoverable, pass the discovery extension in your payment wrapper config:- TypeScript
- Python
- Go
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-rollingPaymentRequired, PaymentPayload or extension schemas.
Common protocol-level mistakes include:
-
The settled
PaymentPayloaddid not carry the extension. Cataloging happens when a facilitator processes aPaymentPayloadthat includes the echoedbazaarextension. A server-side declaration alone catalogs nothing if no paying client echoes it; a settlement whose payload omits the extension catalogs nothing either. -
The echoed declaration is not spec-conformant. Servers advertise bazaar
data in
PaymentRequired(HTTP:PAYMENT-REQUIREDheader; MCP: tool-resultstructuredContent). Clients must echo that data intoPaymentPayload. 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(whenoutputis present) - a relative
resource.url— use an absolute URL - malformed
acceptsentries (e.g.assetas an object instead of a string, or a missing atomic-unitsamount) - service metadata violating the validation rules above — invalid fields are soft-dropped individually
$refor$idvalues in theschemafield that are not same-document JSON Pointer fragments (i.e. do not start with#) — external references such ashttps://...,file://..., or relative URIs are rejected to prevent SSRF/LFI (CWE-918). Only in-document references like"$ref": "#/definitions/foo"are allowed.
- missing
-
Treating the absence of
EXTENSION-RESPONSESas failure. Facilitators may return this header; its absence carries no signal. When present,bazaar.statusandrejectedReasonreflect that facilitator’s outcome. -
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.
GET /discovery/resources?payTo=<address> can confirm what that facilitator
has cataloged for a given payee.
Reference implementations in the x402 repo:
- TypeScript bazaar server — dynamic routes and
routeTemplate - Python bazaar server — same pattern (FastAPI)
- Go bazaar server
Support
- GitHub: github.com/x402-foundation/x402
- Slack: Join x402 Slack
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.