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

# Sellers, services, and meters

> The ZeroClick catalog model: how sellers, services, and meters are identified, where each slug surfaces, and the uniqueness rules that apply.

Your catalog on ZeroClick has three levels. A **seller** is one storefront. It contains **services**, the purchasable things, and each service contains **meters**, the billable measurements within it. Every identifier an agent sees on the storefront, and every identifier your guard sends to ZeroClick, resolves through these three levels. Catalog pricing is a separate concern; [plans and pricing](/concepts/plans-and-pricing) covers it.

## Sellers

A seller is one agent-facing storefront; the dashboard presents it as your store. Its slug names the hosted pay URL: slug `acme` gives `https://acme.pay.zeroclick.io`, and a custom domain such as `agents.acme.com` can front the same storefront. Seller slugs are unique across all of ZeroClick.

Two seller fields do the heavy lifting:

* `upstreamBaseUrl`: the origin ZeroClick forwards paid requests to, such as `https://api.acme.internal`. Agents never see it: they call the pay URL, and ZeroClick maps the path onto your upstream on the signed forward.
* Storefront metadata: name, description, tagline, tags, logo, docs and OpenAPI URLs, contact email. Agents read this metadata when they discover you, both on the storefront and in the machine-readable catalog it serves at `/manifest.json`.

The pay URL is a transparent proxy over the upstream, so the mapping is mechanical. An agent sends the request it would have sent you directly:

```http theme={null}
POST /v1/product-watch HTTP/1.1
Host: acme.pay.zeroclick.io

{ "url": "https://example.com/product/42" }
```

and, once paid, ZeroClick forwards the same method, path, query, and body to `https://api.acme.internal/v1/product-watch` with the `zc-request-id`, `zc-agent-id`, and `zc-signature` headers attached. The full lifecycle is in [how ZeroClick works](/concepts/how-zeroclick-works).

## Services

A service is one purchasable thing: an API, a model, a workflow, or a feature. It has a name, an optional description, and a slug that is unique per seller: two sellers can both have a `product-watch`, but one seller cannot have two.

The service slug is the identifier your integration speaks. Your guard passes it as `serviceSlug` in [allowance checks](/integrate/check-allowances) and [usage reports](/integrate/settle-usage). Your API names it in the `402 payment_required` refusal body that ZeroClick re-prices into a challenge.

## Meters

A meter is one billable measurement within a service: `requests` with unit "request", or `output_tokens` with unit "token". A meter is only a key and a unit: prices attach to meters through plans, so the same meter can cost different amounts on different plans.

Meter keys must match `^[a-z][a-z0-9_]*$` (up to 80 characters) and are unique per service. The key appears as `meterSlug` everywhere usage is named: allowance checks, usage reports, the `zc-usage` response header, and the `usage` items in 402 challenges.

## Where each identifier surfaces

| Level        | Example         | Unique within    | Surfaces as                                                    |
| ------------ | --------------- | ---------------- | -------------------------------------------------------------- |
| Seller slug  | `acme`          | all of ZeroClick | the pay URL host, `acme.pay.zeroclick.io`                      |
| Service slug | `product-watch` | its seller       | `serviceSlug` in guard calls, 402 refusals, and the catalog    |
| Meter key    | `output_tokens` | its service      | `meterSlug` in allowance checks, usage reports, and `zc-usage` |

Seller and service slugs are lowercase kebab-case (`^[a-z0-9]+(?:-[a-z0-9]+)*$`, up to 80 characters); meter keys use underscores instead of hyphens.

## What agents read

The pay URL doubles as the seller's machine-readable surface. Alongside the storefront itself, it serves:

* `/manifest.json`: the live catalog (services, meters, plans, and prices) as JSON. Agents read it at call time, so catalog changes reach buyers without a republish step.
* `/llms.txt` and `/llms-full.txt`: an agent-facing index and full guide for calling your API through ZeroClick, generated from the same catalog.

ZeroClick generates all three from your catalog; none of them is something you author or host.

## Managing the catalog

ZeroClick sets up your catalog with you during onboarding. After that, you manage it in the [dashboard](https://dashboard.zeroclick.io), or with the [REST API](/api-reference/introduction) when you want to automate changes. Sellers, services, and meters are plain resources scoped to your organization. Changing a slug changes the identifier your guard must send, so coordinate slug changes with a deploy of your integration.