Privacy & Data

Onlist is a platform: your requests are fulfilled by independent providers. Privacy on Onlist therefore rests on what every provider commits to, not on a platform-side guarantee. This page states that model plainly, including its limits.

The honest summary

Privacy here has two layers, and neither of them is a platform guarantee:

1. A baseline every provider signs. All providers attest they do not retain or train on your data (provider-attested, not platform-verified, and does not cover third-party model services).
2. An optional per-channel declaration. On top of the baseline, a provider may declare for a channel (one upstream address and key, so it applies to every model sold through it) that the full path to its upstream retains no prompts (zdr), that prompts are not used for training, or for how many days prompts are kept. These declarations are what provider.zdr and provider.data_collection filter on, and they are still seller-declared and not verified by Onlist.

The baseline sentence is deliberately narrow. The words it does not contain matter as much as the words it does:

• It is attested, meaning every provider signs a commitment; it is not measured or audited by Onlist on each request.
• It is not platform-verified: Onlist does not actively probe providers to confirm the commitment.
• It does not cover third-party model services: a provider can commit to its own data handling, but it cannot bind a separate service it uses to fulfill a request.

Universal provider self-attestation

Every provider, at onboarding, must sign a mandatory attestation:

"I commit not to store buyer conversations or use them for training."

Signing is a hard gate. No signature, no storefront: a provider cannot list anything for sale until the attestation is on file.

Because the attestation is universal, it cannot tell providers apart: every provider you could route to has made the same commitment, so filtering on the baseline alone would select everybody. What does vary between providers, and what the per-request privacy fields actually filter on, is the separate per-channel declaration described below.

What the attestation covers, and what it does not

This is the most important caveat on the page. The attestation is scoped to the provider's own conduct, not to the entire request path.

A provider that uses a separate model service can commit to how it handles your prompts in its own infrastructure. It cannot promise that the other service follows the same rules. Any retention by that service is outside the provider's control and outside Onlist's control.

So the wording is always "I commit not to store buyer conversations or use them for training", never "end-to-end zero retention."

Per-channel data policy declarations

A seller can declare a data policy on each channel (one upstream address and key; every model sold through that channel inherits it). Unlike the baseline attestation, the declaration is scoped to the full path to that seller's upstream, so it is a stronger claim than the baseline and it is optional. A seller whose upstreams differ splits them into separate channels.

Anything not declared reads conservatively: prompts may be retained and may be used for training, the same default OpenRouter applies to a provider whose policy it cannot confirm. Onlist never fills a stronger claim in on a seller's behalf, and it never checks a declaration against reality. A seller whose model list is an OpenRouter provider document gets compliance.zdr read into these fields automatically; see For providers.

You can read the declarations three ways:

• The ZDR badge on a provider row on a model page.
• The model catalog: every entry in providers[] carries zdr and data_policy (training, retains_prompts, retention_days).
• GET /api/v1/endpoints/zdr, which lists every (model, seller) endpoint declared ZDR in the same shape OpenRouter serves at the same path. On Onlist this endpoint needs no authentication (OpenRouter's requires a token): the declarations are already printed on the public model pages, so gating them would only add a step to a host swap.

curl https://onlist.io/api/v1/endpoints/zdr

The zdr and data_collection fields

Onlist accepts the OpenRouter-style privacy fields in the provider routing object, so existing request bodies keep working unchanged:

curl https://onlist.io/v1/chat/completions \
  -H "Authorization: Bearer YOUR_ONLIST_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "messages": [{"role": "user", "content": "Hello"}],
    "provider": {
      "zdr": true,
      "data_collection": "deny"
    }
  }'

These fields are enforced. They narrow the candidate pool to listings carrying the matching seller declaration, and when nothing in the pool carries it the request fails with a 503 instead of quietly routing somewhere that does not. A privacy constraint that is silently dropped is worse than an error, so Onlist does not drop it.

Field behavior

Error codes

Both 503s are recoverable: the same request starts working the moment a seller publishes the declaration, so retrying later or relaxing your other constraints are both reasonable responses. They say "no eligible listing" on purpose. The privacy filter runs after max_price and after the declared-context filter, so a listing that does carry the declaration may have been removed by one of your own earlier constraints rather than being missing from the market.

Wrong wire types are a different failure: "zdr": "yes" or "data_collection": 1 cannot be decoded into the provider object at all and return a 400 body-decode error, not a 422.

The constraint holds on every routing path, including reuse of a sticky provider from your previous turn, platform test tokens, and the retry that ignores provider cooldowns. None of them can hand a zdr: true request to a listing that has not declared it.

See Provider routing for the full provider object.

Platform-side temporary retention

For abuse prevention and buyer-seller dispute arbitration, the Onlist platform temporarily retains API request and response content under these rules:

• Scope: for text chat requests, an excerpt of the input sent to the provider and the response content (oversized parts are truncated; embedded media payloads are not stored). Embedding, image and video generation are excluded.
• Duration: at most 7 days, currently defaulting to 3 days, hard-deleted automatically on expiry.
• Access: only platform administrators, and only when handling a dispute or abuse investigation. Never shared with any third party, never used for training.
• Client type: the request User-Agent (client identifier) is kept long-term with usage logs for operational statistics.

This does not contradict provider attestations: an attestation constrains the provider's own retention behavior, while platform-side retention serves the buyer's need for evidence in a dispute. When a disagreement arises, the platform can verify what the buyer sent and what the provider returned at the time.

Requests that ask for ZDR are not retained

When a request carries provider.zdr: true, Onlist skips its own temporary retention for that request: no request or response content is written at all. Otherwise "zero data retention" would be untrue at the platform layer, which is the one layer Onlist can actually control.

These requests are also exempt from content moderation, with exactly one carve-out: the hash of the input is compared against the local blocklist of content that was already blocked before. A hash is not content, so nothing is sent to the moderation provider, and no content, excerpt or evidence is written. If that hash matches, the request is still refused, and the refusal is recorded with metadata only (user, model, hash), never with the content itself.

Enforcement

Onlist does not actively probe providers to test either the baseline attestation or a per-listing declaration. There is no on-request inspection that proves a provider is honoring what it declared.

Enforcement is reactive and reputational:

• Credible reports of a provider retaining or training on conversations are handled through the dispute system.
• A provider found in breach faces suspension of its storefront.

The attestation is a binding commitment, and breaking it is grounds for removal from the platform, but it is enforced after the fact, on evidence, not by continuous verification. A false zdr or training declaration is handled the same way: it is a claim the seller made, and misrepresenting it is a breach.

Where responsibility sits

Responsibility for honoring the attestation sits substantially with the provider, who accepts it through a binding agreement that includes indemnification. The platform's own duties are narrower but real:

1. Don't mislead: describe privacy exactly as it works (provider-attested, not platform-verified, and does not cover third-party model services), without overclaiming, and label every per-listing declaration as the seller's own claim wherever it is shown.
2. Bind providers contractually: require the attestation as a hard onboarding gate so the commitment is enforceable.
3. Act on credible reports: investigate and suspend providers found in breach.

This division is deliberate: Onlist cannot verify what happens inside an independent provider's infrastructure, so it makes the provider contractually accountable and keeps the platform honest about the boundary.

Next steps

• Provider routing: The full provider object, including the error codes zdr and data_collection can return.
• For providers: How a seller declares a data policy, and how an OpenRouter provider document prefills it.
• Limits & headers: Response headers including X-Onlist-Warnings and X-Onlist-Route-Id, and what Onlist does and does not send.