Become a Provider

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

1. Create an account. Sign up at onlist.io as a regular user.

2. 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.

3. 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.

4. 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 review it for the catalog. A model you trained or modified yourself follows the rules in Your own models.

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 captured when the listing is created, either from your own model list or from the mapping field in the wizard. If your upstream later renames a model (for example after switching gateway software, it may only accept a dated id such as claude-haiku-4-5-20251001), you usually do not need to do anything. The first time your upstream rejects the name Onlist sends, that request moves to another provider and Onlist fetches your model list in the background. If the rejected name is not in the list and exactly one name in the list matches the listing, Onlist sends that name from then on and emails you what changed. The new name is a literal from your own list, and the sell name, prices and ratings stay as they are. If no name or more than one name matches, Onlist does not guess: click Manage models on that channel (the dialog fetches your model list again). A listed row whose upstream name is not in your model list shows both names, and Send this name instead switches the listing to the name in the list. Some upstreams list only the dated id and still accept the short name. If calls to such a listing work, you can leave it as is, and Onlist leaves it alone too.

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.

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.

Your own models

If you serve a model you trained, fine-tuned, merged, or otherwise modified, it sells under your own model name, not the name of the model it was built from. When you apply or list it, tell us the base model and what you changed. The platform adds it to the catalog under your provider name and shows the base model on the model page, so buyers know what they are calling.

The reverse is never allowed: a modified model must not be listed under the original model's name. A buyer who calls glm-5.3 expects the model Z.ai released, and serving anything else under that name is model substitution under the Provider Agreement. The platform may decline a model whose origin it cannot verify.

Content policy

Onlist does not list services positioned as uncensored, unfiltered, jailbroken, or built for sexual or adult content, and it does not accept models whose safety behavior has been removed or weakened to enable that content.

The same rule covers everything you publish here. Your store name, description, logo, and listing descriptions must describe your service accurately and must not promote sexual or adult content, uncensored output, or ways around safety measures. Promoting your Onlist listings that way anywhere else counts the same. Applications that do not meet this policy are declined, and live services that break it are removed.

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.

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.

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.
• Long-context tiers: With per-token pricing you can add up to 4 tiers such as "prompts over 200K tokens: $6 input / $22.50 output". A request whose full prompt (cached tokens included) is longer than a tier's threshold is billed entirely at that tier. Thresholds start at 32K tokens and a tier can't be cheaper than the one below it, so your base price is always your lowest price.
• 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.

Buyers see your base price with a tier marker; hovering it lists every tier. Price sorting and max_price use the tier the request will actually hit, so a low base price doesn't win long requests on its own. When you import models from an OpenRouter-compatible upstream, its long-context tiers are prefilled; prices that vary by time of day are prefilled at the highest rate.

Web search. When a buyer brings a model's own search tool (the Responses web_search tool that Codex sends, or Claude's web search tool from Claude Code), Onlist forwards it to your upstream unchanged and, for now, does not bill the searches separately. The search results your upstream adds to the conversation are billed as tokens at your price. If your upstream charges per search, build that cost into your token prices. Onlist's own web search (the web plugin and :online) runs before the request reaches you: Onlist pays for it and keeps its fee, and the results it adds to the prompt are billed as input tokens at your price.

Web search server tool. When a buyer declares the openrouter:web_search server tool, the model decides when to search, and Onlist calls your upstream once per step: one buyer request can reach your upstream several times, at most 6 (up to 5 search rounds plus a final answer), each call carrying the whole conversation so far. All the steps form one settlement and one usage-log row, and each step is priced on its own at your price (a long-context tier applies to a step by that step's own prompt length; a per-request price is charged once per call). The search fee goes to Onlist, as for the plugin. How the steps settle:

• If nothing from the whole request reaches the buyer (no text, reasoning or function call), the request is not charged, so the cost of its intermediate steps is yours, as with any request that produces no output.
• If a step fails after output has reached the buyer, only the steps completed before it are settled. If it fails before any output, the attempt is a failed attempt like any other: it is not charged, and Onlist may retry the request with another provider.
• If the request stops because the buyer's credits or API key limits cannot cover the next step, the steps already completed are still charged, even if nothing reached the buyer: their cost was reserved before they ran.

Keeping prices in sync with your upstream

Onlist never changes your prices for you. When your upstream reprices, open Batch pricing on a channel under My models: it fetches your upstream's current prices, lines them up against every model on that channel, and lets you filter the ones priced below your upstream cost or no longer offered upstream. Pick the upstream price or your current price as the base, add or subtract a percentage, and apply it to the models you tick in one go. Models your upstream no longer offers can be paused from the same dialog.

Where the upstream price comes from matters:

• OpenRouter-compatible upstreams report what they actually charge, in US dollars. Onlist prefills these prices when you list models and flags models you sell below them.
• new-api and one-api relays report their list price in their own credits. It leaves out your group multiplier and the relay's top-up rate, so it may not be what you pay. Onlist shows it as the upstream list price and fills it in only when you turn on Fill in upstream list prices in the wizard. Batch pricing starts from your current price and doesn't flag models below the list price; you can still use the list price as the base with your own percentage.
• Upstreams that publish no prices (sub2api, official APIs) are priced by hand, and batch pricing adjusts your current prices.

Cache performance

Prompt caching is where most of the money is for agent-style traffic: in a typical coding session, cached input tokens outnumber fresh input tokens many times over. Onlist measures, per model, the cache hit rate each provider actually delivers over the last 7 days and uses it in two places:

• Price-sorted routing (:floor / provider.sort: "price") ranks providers by effective price: your list price adjusted by your measured hit rate and the model's input/output mix. A provider that lists a low price but rarely hits the cache ends up more expensive per request than a slightly pricier provider with a high hit rate, and is ranked accordingly.
• Model pages show your hit rate next to your cache prices, graded against the best providers for the same model: green when in line with them, amber when below, red when far below. A 0% hit rate is shown as 0%, not hidden.

Only calls where Onlist picked you first are counted, because failover traffic is cold by definition, and the measurement needs a minimum amount of recent traffic. Below that, your price is ranked as list price times the model-wide average, so a new listing is neither punished nor favored.

The usual causes of a low hit rate are rotating requests across several upstream accounts (each account has its own cache), a gateway that strips cache_control markers, or an upstream that does not support prompt caching for the model. Fixing that lowers what buyers pay and raises your rank at the same time, in the price-sorted order and in the default order alike: the default order counts your delivered price as one of its axes, see How the default order ranks you.

Speed performance

Onlist measures two speed numbers for every model you list, both over the last 7 days:

• Time to first token (TTFT), reported as the median: how long a buyer waits before your first token arrives.
• Throughput, in output tokens per second: output tokens divided by the whole call time, including the wait for the first token, weighted by token count. This is the same definition OpenRouter uses, so holding the answer back and releasing it at the end cannot raise it.

Only streaming calls that Onlist routed to you first are counted. Failover traffic arrives already delayed by another provider, and a non-streaming call has no observable first token, so neither contributes. A listing needs at least 10 qualifying calls in the window before anything is shown or used.

Both numbers are used in two places:

• Model pages show them as their own columns, next to price, cache and uptime. Below the sample threshold the cells show "—" rather than a guess.
• Speed-sorted routing (:nitro, provider.sort: "throughput" or "latency") combines your time to first token with how fast you write after it into how long it takes you to deliver one typical-length answer for that model, and ranks the shortest first. The answer length is the same for every provider of the model, so the order usually matches the throughput column but can differ when providers serve answers of very different lengths. Without enough traffic you sort at the median of the measured providers for that model, so a new listing is neither punished nor favored.

What helps: keep streaming enabled on every listing you sell, keep upstream queueing down (an overloaded account pushes TTFT up long before it starts failing outright), and never buffer the response at your gateway to release it in one piece — time to first token then equals the whole call, and both your throughput and the speed you are ranked on come out worst of all.

How the default order ranks you

Most buyers never set a sort, so the default order, called Smart, decides most of the traffic. Like OpenRouter's default, it hands each new conversation to a provider drawn with probability proportional to the inverse square of the delivered price, then adjusts for reliability and speed and multiplies by the quality score (authenticity inspections where the model has them, buyer ratings otherwise):

weight   = (quality × delivery)^4 × (cheapest cost ÷ your cost)^2
delivery = 0.8 × availability + 0.2 × speed

• Delivered price. Your cost per token, using the effective price from Cache performance. At twice the cheapest provider's cost you get a quarter of its weight; at three times, a ninth; at eight times, 1/64.
• Availability. Your success rate on that model over the last 24 hours, counting buyers' calls only and only the failures that are yours: an upstream outage behind you counts, a buyer's malformed request does not. A buyer whose client keeps retrying while you are down counts at most its usual number of successful calls per minute on that model (at least one) as failures in any minute, so a short outage is not multiplied by an aggressive retry loop, and a failure that happens after the buyer has already disconnected does not count. The rate is first pulled toward the average of all providers on the model with a weight worth about 20 requests, so a new listing starts at the typical level for that model rather than at a perfect score, and moves toward its own record as traffic arrives. Then every 1% of failure rate costs 0.1 points: 99% scores 0.9, 95% scores 0.5, and 90% or below scores 0.
• Speed. Your measured speed divided by the fastest provider's, using the same time-to-first-token plus throughput measurement as Speed performance. Below the sample threshold you are placed at the median of the measured providers.

The exchange rates, in price terms: one point of failure rate weighs about as much as being 18% more expensive, five points about as much as 2.8 times the price, and at 90% or below you drop out of the draw. Being half as fast weighs about as much as being 23% more expensive. Buyer ratings only break ties, because they are the easiest signal to game.

Smart does not hand all traffic to first place, but price decides most of it: the cheapest reliable providers get nearly all new conversations, a provider priced close to them gets a real share, and an expensive listing keeps a trickle that keeps its numbers current. A buyer who sets an explicit sort, an order, or a :floor / :nitro suffix turns the draw off and gets the strict ranking instead.

What helps, in order of impact: price close to the cheapest provider on the model (twice the price is a quarter of the traffic); raise your cache hit rate so your delivered price drops without touching the list price; keep the failure rate down (every point is worth about 18% of price); keep streaming on and time to first token low so the speed axis counts for you.

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:

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

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

Anthropic 1-hour cache writes settle at the 1-hour rate only when the buyer's request asked for a 1-hour breakpoint ("ttl": "1h"). If your gateway upgrades the buyer's cache breakpoints to 1 hour on its own (some proxies do this for subscription credentials), the 1-hour writes it reports settle at the 5-minute rate. The buyer pays for the cache they asked for, and your earnings are computed from that same price.

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:

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.