Skip to main content
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 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:
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.

​
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 and usage reports. 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

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, or with the REST API 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.