How to Enable OpenRouter ZDR Per Request

01

Overview

OpenRouter lets developers make Zero Data Retention an explicit routing requirement instead of relying on whichever provider happens to receive a request.

The fastest way to enforce it for one request is to set provider.zdr to true. OpenRouter says that request will then route only to endpoints that qualify for its Zero Data Retention policy.

02

The simplest request-level setup

Add a provider block to the request and enable ZDR:

json { "model": "your-model-id", "messages": [{"role": "user", "content": "Hello"}], "provider": { "zdr": true } }

The exact model ID is separate from the privacy rule. ZDR filters eligible provider endpoints for that request.

03

Add data_collection deny when training/storage matters too

OpenRouter documents another provider control named data_collection. Set it to deny when you want routing to exclude endpoints that store user data non-transiently and may use it for training.

json { "provider": { "zdr": true, "data_collection": "deny" } }

These settings overlap but are not synonyms. zdr: true is about retaining prompts and responses after inference. data_collection: "deny" is a broader exclusion for endpoints whose policies allow non-transient storage or training-related collection.

04

Account-level ZDR

If every request from an account should require ZDR, OpenRouter also exposes privacy settings that can enforce the policy without changing each request body.

This is useful when privacy is an organizational requirement rather than a per-feature choice. It also reduces the chance that one developer forgets to set the field in a new integration.

05

Model-group and guardrail enforcement

OpenRouter says ZDR can also be enforced for model groups and through guardrails. This lets teams define privacy policy centrally while still giving applications access to multiple models.

The important behavior is compositional: request-level ZDR does not weaken a stricter account or guardrail rule. If any applicable layer requires ZDR, the request remains constrained to ZDR-eligible endpoints.

06

Add US or EU in-region routing when location matters

ZDR does not control geography. If processing must occur in a specific region, use OpenRouter's region-specific API base URL in addition to ZDR.

OpenRouter documents:

• https://us.openrouter.ai/api/v1 for US in-region routing;
• https://eu.openrouter.ai/api/v1 for EU in-region routing.

A region requirement narrows eligible providers by processing location. ZDR narrows them by retention policy. Combining both gives a stricter route than either control alone.

07

What should happen if no eligible endpoint exists?

Privacy filters reduce the provider pool. A model that works under unrestricted routing may have no endpoint that satisfies ZDR, no-training and region restrictions simultaneously.

Do not design production code under the assumption that a fallback will always exist. Handle routing failures explicitly and decide whether the application should stop, ask the user to choose another model, or use a pre-approved alternative.

The safe policy is never to relax privacy requirements silently just to make the request succeed.

08

Do not hard-code a permanent ZDR model list

OpenRouter tracks policy at the endpoint level. The same model can be served by different providers with different data policies.

That means documentation that says “Model X is ZDR” can become wrong if provider availability changes. Check live endpoint policy data before deploying sensitive workloads and periodically revalidate long-running systems.

09

Audit the rest of the request path

Even a correctly configured ZDR request can still leak sensitive information through another layer.

Review:

• application request logs;
• observability and tracing platforms;
• tool-call logs;
• plugin storage;
• prompt caches;
• database persistence;
• error-reporting systems;
• analytics payloads.

ZDR is not a replacement for application-level data governance.

10

Recommended production pattern

For a workload containing sensitive business or customer data:

1. enforce ZDR at account or guardrail level if it is mandatory;
2. keep provider.zdr: true in sensitive request paths as an explicit defense-in-depth signal;
3. add data_collection: "deny" where training/storage restrictions matter;
4. use the appropriate US or EU endpoint if residency matters;
5. define a known-good fallback model set that satisfies the same policy;
6. log metadata rather than raw prompt content wherever possible;
7. recheck provider eligibility periodically.

11

Common mistake: treating ZDR as on-prem privacy

A ZDR request still reaches an external inference provider. It simply requires that eligible provider not retain the prompt or response after processing.

If policy says data must never leave customer-controlled infrastructure, use self-hosted inference or a provider arrangement explicitly designed for that requirement.

12

Bottom line

OpenRouter makes ZDR practical because it can be enforced at multiple levels and can travel with a model-agnostic routing architecture.

For most sensitive deployments, zdr: true should be viewed as one layer in a broader policy stack that also covers training/storage, region, logs, tools and caches.