> ## Documentation Index
> Fetch the complete documentation index at: https://developers.fireblocks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build an Agentic Product Catalog

> Declare payment-gated products on the Fireblocks x402 Facilitator and publish them so AI agents can discover, price, and pay for your services automatically.

<Note>
  **Open-source or hosted? This page describes the open-source facilitator that you run yourself.** Fireblocks also offers a **fully managed, fully secured hosted x402 Facilitator** — production-grade security, operational support, monitoring, and a managed endpoint, with no infrastructure for you to run or upgrade. [Talk to us about early access](https://www.fireblocks.com/#request-demo).
</Note>

A product catalog is how you describe what you sell to autonomous agents. On the Fireblocks x402 Facilitator, each product is a payment-gated HTTP endpoint with a price, an accepted-asset list, and metadata. Your own agents and customers reach products directly through the `402` flow on your server. The broader agent ecosystem finds them through the public discovery API, which follows the same shape as the [Coinbase x402 Bazaar](https://docs.cdp.coinbase.com/x402/bazaar) catalog. This page covers declaring products, pricing them across assets, and deciding which ones to publish.

With x402 you monetize an endpoint and let machines buy access without an account, a subscription, or a human in the loop. To fund an agent and control what it spends, see [Fund and Control Agent Spending](/docs/x402-agent-spending-controls).

## What a product is

A product binds a URL path on your server to a price and a set of accepted assets. The facilitator stores products per configuration; each product carries these fields:

| Field             | Purpose                                                                                  |
| ----------------- | ---------------------------------------------------------------------------------------- |
| `product_id`      | Server-generated identifier (`prod_…`).                                                  |
| `name`            | Human-readable label shown to operators.                                                 |
| `endpoint`        | The URL path you gate, starting with `/` (for example, `/premium`).                      |
| `scheme`          | x402 payment scheme: `exact` (fixed price) or `upto` (metered ceiling).                  |
| `usd_price`       | USD price in fractional dollars. Required whenever any pricing row converts from USD.    |
| `pricing[]`       | One row per accepted asset. Each row is a fixed native amount or a USD-converted amount. |
| `description`     | Free-text shown in the discovery catalog. Falls back to `name` when absent.              |
| `mime_type`       | Response content type advertised to agents. Defaults to `application/json`.              |
| `category`        | Optional grouping used as a discovery filter (for example, `data`, `inference`).         |
| `is_discoverable` | Whether the product appears in the public discovery API. Defaults to `false`.            |

A product is the unit an agent reasons about: a single endpoint, a price it can compare, and an asset it already holds.

## Declare a product

Products are managed with the `x402` CLI. (Creating and editing products over HTTP is intentionally read-only; the management API exposes products for inspection only.) The simplest product gates one endpoint at a fixed USD price, settled in USDC:

```bash theme={"system"}
x402 products add \
  --name "Premium Data" \
  --endpoint /premium \
  --usd-price 0.01 \
  --asset USDC_BASECHAIN_ETH_TEST5_8SH8
```

To price directly in an asset's base units instead of converting from USD, pass the amount with the asset or use `--price`:

```bash theme={"system"}
# 0.10 USDC expressed in base units (6 decimals)
x402 products add --name "Premium" --endpoint /premium \
  --asset USDC_BASECHAIN_ETH_TEST5_8SH8:100000

# Equivalent legacy shorthand for a single-asset native amount
x402 products add --name "Premium" --endpoint /premium \
  --asset USDC_BASECHAIN_ETH_TEST5_8SH8 --price 100000
```

Each accepted asset must already be imported into the facilitator's asset catalog (`x402 assets import`) before you can reference it in a product. Endpoints are unique within a configuration: adding a second product on a path that already exists returns `409`.

### Inspect the catalog

```bash theme={"system"}
x402 products list                 # table of products in the configuration
x402 products show <productId>      # full record, with each pricing row's asset joined
x402 products remove <productId>    # delete a product
```

## Price across multiple assets

Each product carries a `pricing[]` table with one row per accepted asset. A row is either **native-denomination** (an explicit `amount` in the asset's base units) or **USD-converted** (`amount` is null, and the product's `usd_price` is converted at request time). You can mix both on the same product. Repeat `--asset` to accept several assets at once:

```bash theme={"system"}
x402 products add --name "Premium" --endpoint /premium --usd-price 0.10 \
  --asset USDC_BASE \
  --asset USDC_POLYGON:90000 \
  --asset ETH_BASE
```

This advertises three ways to pay for the same resource: convert \$0.10 to USDC on Base, charge a fixed 0.09 USDC on Polygon, and convert \$0.10 to ETH at the current rate. The facilitator emits one `accepts[]` entry per pricing row in the `402` response, and the agent picks whichever asset it holds. For how USD conversion resolves and how the same asset can be offered under several transfer mechanisms, see [Pricing modes](/docs/x402-facilitator-integration#pricing-modes).

<Tip>
  Offer at least one stablecoin priced row. Agents compare quotes across services, and a stable, low-gas option (for example, USDC on Base) is the path most buyers can settle immediately.
</Tip>

## Publish to the discovery catalog

By default a product is private: agents reach it only by hitting your endpoint and receiving a `402`. To list a product in the public discovery API, mark it discoverable and give it a category:

```bash theme={"system"}
x402 products add --name "Premium Data" --endpoint /premium \
  --usd-price 0.01 --asset USDC_BASE \
  --description "Real-time market data feed" \
  --category data \
  --discoverable
```

The facilitator exposes the catalog at `GET /api/discovery/resources`. This endpoint is **public** (no authentication) and is scoped to a configuration by the request's `Host` header, so each merchant's public host serves only its own discoverable products.

```bash theme={"system"}
curl "https://pay.myservice.com/api/discovery/resources?category=data&limit=20"
```

The response lists each discoverable product as a resource an agent can act on:

```json theme={"system"}
{
  "x402Version": 2,
  "items": [
    {
      "resource": "https://pay.myservice.com/premium",
      "type": "http",
      "x402Version": 2,
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "10000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
        }
      ],
      "lastUpdated": 1776521334,
      "metadata": {
        "category": "data",
        "description": "Real-time market data feed",
        "mimeType": "application/json"
      }
    }
  ],
  "pagination": { "limit": 20, "offset": 0, "total": 1 }
}
```

Query parameters: `category` filters by product category, `type` accepts `http` (the only supported resource type today), and `limit` (max 100) plus `offset` paginate.

<Note>
  **Only fixed-price rows appear in discovery.** The catalog is a static index, so a discoverable product surfaces one `accepts[]` entry per **native-denomination** pricing row. USD-converted rows (where `amount` is null) are skipped, because their price depends on a live exchange rate. A product whose rows are all USD-converted still works through the live `402` flow, but it will not appear in the catalog. To list in discovery, give the product at least one native-denomination row.
</Note>

### How discovery fits the wider ecosystem

The discovery response shape matches the Coinbase x402 Bazaar catalog format, so agents and directories built for the Bazaar can read your facilitator's catalog directly. Discovery and settlement stay separate: the discovery API only advertises what you sell, while payment still flows through your `402` endpoint and the `/api/payments/*` API. Publishing a product does not expose your Fireblocks vault, your API keys, or your customer traffic.

## Build a catalog for your customers and for the open market

The `is_discoverable` flag lets one facilitator serve two audiences from the same product set:

* **Your own agents and customers.** Leave products private (`is_discoverable: false`). They are reachable only by callers who already know your endpoint, which suits internal tools, partner integrations, and paid APIs you market yourself. The `402` flow and the [payment processing API](/docs/x402-facilitator-integration#the-payment-processing-api) work identically whether or not a product is discoverable.
* **The open agent ecosystem.** Mark products discoverable so any agent browsing the catalog can find, price, and pay for them without prior knowledge of your service.

A common pattern is a tiered catalog: a small set of discoverable products as a public on-ramp, with richer or higher-value endpoints kept private for authenticated partners.

### Host many catalogs on one facilitator

A single facilitator process can host a separate catalog per merchant using one configuration per merchant. Each configuration has its own `public_host`, Fireblocks vault, API keys, and product list, and discovery requests are routed to the right catalog by `Host` header. This is the model a payment-service provider uses to run catalogs on behalf of many sellers. See [Multiple merchants on one facilitator](/docs/x402-facilitator-operations#multiple-merchants-on-one-facilitator).

## How an agent buys from your catalog

Once a product is published, the purchase path is fully machine-driven:

```mermaid theme={"system"}
sequenceDiagram
    participant A as Buyer agent
    participant D as Discovery API
    participant M as Your server
    participant F as Facilitator

    A->>D: GET /api/discovery/resources?category=data
    D-->>A: catalog (resource URLs, prices, assets)
    A->>M: GET /premium
    M-->>A: 402 Payment Required (quote)
    Note over A: Sign EIP-712 authorization
    A->>M: GET /premium + payment-signature
    M->>F: verify + settle
    F-->>M: settled on-chain
    M-->>A: 200 OK + resource
```

1. The agent browses the discovery catalog and selects a resource whose price and asset suit it.
2. The agent requests the resource and receives a `402` quote (or fetches it ahead of time with [`POST /api/payments/create`](/docs/x402-facilitator-integration#post-apipaymentscreate)).
3. The agent signs an EIP-712 authorization and retries with a `payment-signature` header.
4. Your middleware verifies and settles through the facilitator, then serves the resource. Whether you settle before or after serving is the [settlement mode](/docs/x402-facilitator-integration#when-to-settle) choice.

You never write agent-facing payment code beyond the middleware that returns the `402` and calls verify/settle. The catalog does the rest.

## What to read next

* [Integration](/docs/x402-facilitator-integration) — the middleware pattern, the payment processing API, transfer mechanisms, and pricing modes.
* [Fund and Control Agent Spending](/docs/x402-agent-spending-controls) — funding an agent from a Fireblocks vault and controlling what it spends.
* [Operating and production](/docs/x402-facilitator-operations) — config file, auth model, management API, CLI reference, and multi-merchant hosting.