Supply

Providers

Expose an API through Tollex and agents can find it, check what it costs, pay for it and get a receipt, without you building any of that.

Describe the capability

There are two ways to describe your API. Both produce the same capability model.

• An OpenAPI 3 document. Each operation becomes a capability. Set the price per call with the x-tollex-price extension (atomic USDG), or give the importer a default. An operation with no price is skipped, so nothing is ever listed as free by accident.
• A manifest. A short, explicit description of endpoints, schemas, prices and authentication, for APIs without a usable OpenAPI document.

const manifest: ProviderManifestInput = {
  id: "acme.marketdata",
  name: "Acme market data",
  baseUrl: "https://api.acme-data.example/v2",
  network: NETWORK,
  asset: { address: USDG_ADDRESS, symbol: "USDG" },
  source: "provider manifest v3, reviewed 2026-10-02",
  // A reference, never the key itself. The operator resolves it at call time.
  auth: [{ kind: "API_KEY_HEADER", name: "key", param: "X-Api-Key", secretRef: "env:ACME_API_KEY" }],
  endpoints: [
    {
      id: "acme_spot_price",
      name: "Spot price",
      description: "Latest spot price for a trading pair, with the exchange timestamp.",
      method: "GET",
      path: "/spot/{pair}",
      pathParams: ["pair"],
      inputSchema: {
        type: "object",
        properties: { pair: { type: "string", pattern: "^[A-Z]{2,6}-[A-Z]{2,6}$" } },
        required: ["pair"],
        additionalProperties: false,
      },
      price: 2_000n, // atomic USDG per successful call (0.002 USDG)
      tags: ["market", "price", "spot"],
      category: "market",
    },
  ],
};
const provider = new ManifestToolProvider(manifest, { secrets: new DefaultSecretResolver() });

How schemas are ingested

• Local $refs are resolved to a fixed depth. External references are refused, and the operation is skipped with a reason.
• Path, query and JSON body parameters become one strict input schema. Cookie parameters are refused.
• Credential headers such as Authorization, Cookie and X-Api-Key are removed from input schemas, so an agent can never supply them.
• Operations other than GET are skipped unless writes are explicitly allowed for them.
• The import returns a report of what was imported, what was skipped and why.

Credentials

Manifests hold references to secrets, such as env:ACME_API_KEY, never the secrets themselves. The operator resolves each reference at call time. Values never appear in schemas, the catalogue, receipts, health output, logs or error messages. A missing credential fails the call rather than sending it unauthenticated.

Outbound calls

Calls to your API go through a guarded fetch. Private and internal addresses are refused, and checked again at connect time so a DNS change cannot slip past. Redirects are followed at most three times, each target validated again. Requests time out, responses are size-limited, and no cookies or caller credentials are forwarded.

How agents find you

Once registered, your capabilities appear in the catalogue, in /v1/resolve plans, in the OpenAPI document, as A2A skills, as MCP tools, and in the Bazaar metadata on each payment challenge. Agents with a provider allow list can name you explicitly.

How payment works

Agents pay the Tollex deployment that serves your capability, in USDG, to the address that deployment configures. The deployment calls your API with your credentials. Payouts between an operator and its providers are arranged between them; Tollex does not split payments on chain today.

Check before you join

tollex provider inspect <url or file> shows what Tollex would import from an OpenAPI document or manifest, and tollex provider validate lists problems as stable codes such as MISSING_PRICE, INVALID_SCHEMA, PRIVATE_NETWORK_TARGET or UNSUPPORTED_AUTH. Neither imports anything. MCP servers, A2A agents, llms.txt files and x402 endpoints can be inspected but are not imported as priced capabilities.

An operator then imports the source, and the service lists the new capabilities from its next start.

Health and reputation

Tollex records what it observes about each provider over the last 30 days and reports each dimension separately, with its sample size. There is no blended star rating.

A dimension with no observations is reported as unavailable, not as zero and not as perfect. A ratio from fewer than 20 observations is marked as too few to rely on.

Schema changes are classified structurally (a new optional field is additive; a new required input or a removed output field is breaking; anything the classifier cannot model is unknown, never compatible). Agents can require stability with requireStableSchemaForMs and maxBreakingChanges30d.