Become a Provider | Onlist Docs

Onlist is an open platform. If you provide API access to AI models, you can publish your service and earn revenue from buyer traffic.

How it works

Onlist connects buyers (developers who consume AI APIs) with providers (individuals or organizations that offer AI model access). As a provider, you connect the API endpoints used to deliver your service. Onlist handles routing, billing, settlement, and the buyer-facing storefront.

Getting started

Create an account. Sign up at onlist.io as a regular user.
Apply to become a provider. Go to Become a Provider and submit your application. You will need to:
- Choose a provider slug (your storefront URL, e.g. alice-shop).
- Sign the mandatory privacy attestation: "I commit not to store buyer conversations or use them for training." This is a hard gate. See Privacy & Data.
Configure API access. Once approved, add the API connections used to deliver your service in the provider dashboard. Each connection needs a base URL and API key.
List models. Models are auto-discovered from your API connections. Review the detected models, choose a billing mode, set your pricing, and publish listings to the platform.

A listing only goes public and starts receiving traffic once its model name exists in the platform catalog. If your upstream serves a cataloged model under a different name (different case, a vendor prefix, a suffix), the listing lands as Not in catalog yet and you can map it to the cataloged name from the listing row, both during the wizard and afterwards. Mapping changes the name buyers see; the name Onlist sends to your upstream stays exactly what your API expects. Only map when it really is the same model. If the model is genuinely new and nowhere in the catalog, leave the listing as it is and the platform will add the model.

The name Onlist sends upstream

Every listing carries two names, and they are allowed to differ.

The sell name is what buyers see and call. It has to be a name the platform catalog carries.
The upstream name is the exact literal Onlist puts in the model field when it calls your API. It is whatever your own model list returned, or whatever you typed in the mapping field.

Onlist never normalizes the upstream name: no case folding, no vendor prefix added or removed, no suffix stripped, no family rewriting. If your API answers to deepseek/deepseek-chat, that is exactly what we send, even when the model sells here as deepseek-chat. That is why a service that fronts another aggregator works without any extra configuration on your side.

Mapping a listing to a cataloged name changes only the sell name. The upstream name stays exactly as it was first captured, so mapping can never break a working connection. When the two names differ, the listing row shows the second one as Upstream name: X. The upstream name is fixed when the listing is created, either from your own model list or from the mapping field in the wizard; to change it, delete the listing and publish the model again under the name your API expects.

The only characters we reject in an upstream name are the ones that cannot survive an HTTP call: an empty value, leading or trailing spaces, control characters, and anything longer than 256 bytes.

If your model list uses the OpenRouter provider fields

If your /v1/models response is an OpenRouter provider document, Onlist reads the extra fields when you connect a service or refresh its model list. Nothing changes for a plain OpenAI-shaped list: the id is used as both the sell-name candidate and the upstream name, exactly as before.

Field	What Onlist does with it
`id`	Becomes the upstream name: the literal we send back to you.
`openrouter.slug`	Becomes the sell name, when that slug is in the platform catalog. The row shows the mapping, and `id` stays as the upstream name.
`is_free`	The row is disabled in the wizard. Free variants (`:free`) cannot be listed yet, and submitting one is rejected.
`is_ready: false`	Shown on the row as Marked not ready by your upstream. You can still list it.
`deprecation_date`	Shown on the row as an upstream deprecation date. You can still list it.
`compliance.zdr`	Read for information only. When some or all of your models declare it, the wizard tells you how many do, so you can declare zero data retention on the channel (Edit channel) if the whole channel qualifies. Nothing is prefilled.

These fields are read as your own declaration and passed through as-is. The platform does not verify them, and it does not query anyone else about your models.

Data policy declaration

Every provider signs the same privacy attestation at onboarding, and that attestation covers your own conduct. On top of it, you can optionally declare a data policy per channel. A channel is one upstream address and one key, so its policy is the same for every model sold through it; if two upstreams differ, split them into two channels. The declaration is a stronger claim, because it covers the full path to your upstream, not just your own systems. Buyers can filter on it, so declaring accurately matters more than declaring generously.

Setting	Wire key	What you are saying
Zero data retention	`zdr`	Nothing on the full path to your upstream stores prompts, and nothing trains on them. Forces a retention period of 0.
Prompts may be used for training	`trains_on_prompts`	Whether prompts may be used to train models anywhere on that path. Left alone, this stays on, the conservative reading.
Retention days	`retention_days`	How long prompts are kept on that path, `0` to `3650`. `0` means not declared or not applicable, not "kept for zero days".

You set these when creating a channel, and afterwards in Edit channel; a change applies at once to every model on that channel. Declaring nothing is a valid choice: an undeclared channel reads as "prompts may be retained and may be used for training", which is exactly what buyers should assume when nobody has said otherwise.

Caution

If you resell another API, you can only declare zero data retention when that service also retains nothing, for example under a contract you hold with it. Reselling a vendor that keeps prompts for abuse review means you cannot declare zdr, even though you keep nothing yourself. Onlist does not verify declarations, and everywhere a declaration is shown it is labeled as your claim, not a platform finding. A declaration that turns out to be false is handled as a breach of the provider agreement, the same as a breach of the attestation.

Two things follow from a zdr declaration that are worth knowing before you turn it on:

Buyers who send provider.zdr: true will only reach listings that declare it. Until sellers declare, those requests fail with 503 no_zdr_provider_available, so declaring is what makes that traffic reachable at all.
Onlist skips its own temporary retention for a request that asked for ZDR. That request has no platform-side record of what was sent or returned, which also means neither side can lean on platform evidence if it is later disputed.

Pricing

You set your own prices in USD. There is no minimum or maximum. Pricing is transparent: buyers see your rates on the Models page and can filter or sort by price.

Per-token pricing: Set separate USD prices for input and output tokens (for example, $3.00 / 1M input tokens and $15.00 / 1M output tokens).
Per-request pricing: Set one USD price for each completed request.
Dynamic pricing: Where supported, calculate a request price from its usage and request parameters.
Prices are entered as USD amounts. The internal ratio system is not exposed to you.

Tip

Buyers can sort by price (:floor suffix or provider.sort: "price"). Competitive pricing directly increases your traffic. Check the Models page to see current market rates.

Commission

Onlist takes a platform commission on each settled request. The commission rate is displayed in your provider dashboard. Your earnings page shows net revenue after commission.

Settlement

Settlement is per-request and real-time:

A buyer sends a request routed to your listing.
Onlist holds the estimated cost in escrow from the buyer's wallet.
The request completes and Onlist records the usage and pricing inputs needed for settlement.
The actual cost is calculated using the billing mode and price configured for your listing.
Your net earnings (after commission) are credited to your provider balance.

There is no monthly invoice cycle. Earnings accumulate in real-time.

Service health and cooldowns

When a request to one of your connections fails, Onlist routes the next buyer elsewhere for a while instead of sending more traffic into a failing service. How long, and how much of your shop it affects, depends on what failed:

What happened	Scope	Back-off
Timeout, connection error, `5xx`	The connection	10s, 30s, 1m, 2m, then 10m for repeats
`429` with no upstream `Retry-After`	The connection	30s, 2m, 10m, then 30m
`401` invalid key, `402` upstream out of credit	The connection	24h: both need a human to fix
`403` on one model, `404 model not found`	That one model on that connection	10m, 1h, 6h, then 24h

The last row is model-scoped on purpose: one model disappearing upstream does not take the rest of your shop off the market. An upstream Retry-After is honored as sent, and a successful request clears the cooldown.

Your provider dashboard makes this visible rather than leaving you to guess from a traffic drop:

The overview page has a service status card and lists the models currently cooling down, with the reason for each.
Every listing row shows its own cooldown state.
You can test a single model from the dashboard. A successful test unfreezes that model immediately, and only that model, which is the fastest way to come back after you fix the upstream.
Repeated cooldowns also reach you by email as a summary, capped at two per rolling 24 hours and at least 6 hours apart, so a broken connection does not turn into an inbox flood.

API requirements

Supported protocols: OpenAI Chat Completions, Anthropic Messages, Gemini, and several media endpoints (video generation, music generation, reranking).
What you provide: A base URL and API key for each API connection. Onlist handles the rest.
Credential-only services (AWS Bedrock, Google Vertex, etc.) are not supported for provider onboarding. Your service must expose URL-and-key API access.

Provider dashboard

Once approved, your provider dashboard gives you:

API connection management: Add, edit, or disable API connections.
Model listings: View auto-discovered models, set prices, map upstream names onto cataloged models, and toggle visibility.
Earnings: Track net revenue and see per-request settlement details.
Reviews: Read buyer reviews of your service.

Questions?

If you have questions about becoming a provider, reach out through the Support system.