Publish tools

Publish a tool. Get paid when it's used.

If you have an API worth using, Sigma Domain gives it a distribution channel and a meter. You set the price; we handle the billing.

Two ways in

Ask for it, or paste it

You don't need to email us and you don't need us to run anything for you. Host your API wherever you like; Sigma Domain calls it.

Just ask. In any conversation, say "import the API at https://your-service.com/openapi.json". Sigma Domain reads the documentation, works out every endpoint, and registers them as tools — the whole API in one request, without you filling in a form.

Or paste it. Open Toolkit, click + Add Tool, and paste an OpenAPI spec, code with JSDoc comments, or a plain-English description of a single endpoint. You get the extracted name, parameters, method and auth type back to correct before saving.

Either way it's live immediately — no review queue — and attributed to you as the author.

A whole API

Point it at your published docs and every endpoint is imported at once. Best when you already have an OpenAPI spec online.

A single endpoint

Paste a spec, JSDoc'd code, or just describe it. Best for one tool, or when your API isn't publicly documented.

Price it

Set a price per call and, if you want, a free allowance so people can try it first. Leave it at zero to publish free.

A tool is a declarative API-call definition — a name, an endpoint, its parameters and how it authenticates. Sigma Domain calls your service; it doesn't run code you upload. If it's reachable over HTTPS and you can describe it, it can be a tool.

Two things to know before you register anything.

Tools you add are public and callable by anyone on the platform, including guests. There's no visibility control in this flow yet, so don't register an endpoint you need kept private.

If the API you're adding is already in the marketplace and you want to list as a second seller, that one case still needs a conversation — we're gating duplicate sellers while we work through volume. Everything else is self-serve.

Worked example

What actually goes in, and what comes out

Say you run a service that looks up a company by its domain. You paste this — an ordinary OpenAPI fragment:

paths: /v1/company: get: summary: Look up a company by domain parameters: - name: domain in: query required: true schema: { type: string }security: - apiKey: []

You get back a tool definition to check before saving:

Name — company-lookup
Endpoint — GET https://your-service.com/v1/company
Parameter — domain (string, required)
Auth — API key

From then on nobody types any of that. They ask "who owns stripe.com?" and the assistant works out that your tool answers it, fills in the parameter, calls your endpoint, and bills the call to their account at your price.

The full walkthrough, including the conversational route and what to do when the parse gets something wrong, is in Registering your own tools.

Billing

The part you'd otherwise have to build

The hard part of selling an API is rarely the API. It's metering, invoicing, quotas, fraud, failed cards and chasing people who exceed their limit. That layer already exists here.

Per-call pricing. Every invocation is counted and priced at the rate you set.
Free allowances. Let users evaluate your tool before they're charged.
One key for the user. They pay Sigma Domain, not each publisher separately — one account, one balance, every tool.
Usage analytics. See which calls are made, how often, and what they earned.
Programmatic access. Issue API keys and reach your tools directly, outside the chat interface, with the same metering.

A standalone API needs its own users, docs, auth, billing and support before it earns anything. A tool published here inherits all of that, and reaches people who don't know your API exists — they only know what they're trying to get done.

Plans and pricing · Open Sigma Domain and add your first tool