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

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

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 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, 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 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."

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.

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.

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, and does not cover third-party model services), 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.