Privacy & Data

Onlist is a platform: your requests are fulfilled by independent providers (often relay operators). 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

All providers attest they do not retain or train on your data (provider-attested, not platform-verified, excludes upstream).

That sentence is the whole privacy stance, and it 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 excludes upstream: a provider can promise its own relay behavior, but it cannot bind the AI provider it resells.

Universal provider self-attestation

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

"I, the relay, do not retain your conversations and do not train on them."

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, the provider pool is homogeneous: every provider you could route to has made the same commitment. There is no class of providers who skipped it. That is why Onlist has no per-request privacy filter — there is nothing to filter on. You are never choosing between "private" and "non-private" providers, because they all attest the same thing.

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 resells OpenAI or Anthropic can promise that its relay does not store or train on your prompts. It cannot promise that the upstream provider behaves the same way. For example, OpenAI retains API data for roughly 30 days for abuse monitoring under its standard terms. That retention is outside the provider's control and outside Onlist's control.

So the wording is always "I (the relay) don't store or train on your data" — never "end-to-end zero retention."

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 accepted but do not drive routing. Because every provider already attests the same thing, there is no narrower pool for zdr:true or data_collection:"deny" to select. The request succeeds; the fields simply do not change which provider fulfills it, and they may emit a warning.

Field behavior

When a privacy field is ignored for routing, Onlist surfaces it in the X-Onlist-Warnings response header, for example:

X-Onlist-Warnings: ignored: provider.zdr, ignored: provider.data_collection

See Provider routing for the full provider object and how X-Onlist-Warnings reports ignored fields.

Enforcement

Onlist does not actively probe providers to test their attestation. There is no on-request inspection that proves a provider is honoring its commitment.

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.

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, excludes upstream), without overclaiming.
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 how zdr and data_collection are handled and reported in X-Onlist-Warnings.
• Limits & headers — Response headers including X-Onlist-Warnings and X-Onlist-Route-Id, and what Onlist does and does not send.