How OpenRouter Manages Data Policies
OpenRouter works with providers to understand each of their data policies and structures the policy data in a way that gives you control over which providers you want to route to. Note that a provider’s general policy may differ from the specific policy for a given endpoint. OpenRouter keeps track of the specific policy for each endpoint, works with providers to keep these policies up to date, and in some cases creates special agreements with providers to ensure data retention or training policies that are more privacy-focused than their default policies.If OpenRouter is not able to establish or ascertain a clear policy for a provider or endpoint, we take a conservative stance and assume that the endpoint both retains and trains on data and mark it as such.
Per-Model-Group ZDR Enforcement
Rather than a single global toggle, OpenRouter lets you enforce ZDR independently for different model groups. This is available in both your account-level privacy settings and in guardrails. The five model group scopes are:Account-level settings
In your privacy settings, each model group has its own toggle. Enabling a scope restricts all your requests to ZDR endpoints for that model group.Guardrail-level settings
When creating or editing a guardrail, you can set ZDR independently for each model group. This lets you apply different ZDR policies to different API keys or organization members. In the API, these are represented as separate fields on the guardrail object:The legacy
enforce_zdr field is deprecated. When provided, its value is copied into any per-model-group fields that are not explicitly set on the request. Use the per-model-group fields directly for new integrations.Per-Request ZDR Enforcement
In addition to account-level and guardrail-level settings, you can enforce Zero Data Retention on a per-request basis using thezdr parameter in your API calls.
The request-level zdr parameter operates as an “OR” with your account-wide and guardrail ZDR settings. If any is enabled, ZDR enforcement will be applied. This means the per-request parameter can only be used to ensure ZDR is enabled for a specific request, not to override or disable account-wide or guardrail enforcement.
This is useful for customers who don’t want to globally enforce ZDR but need to ensure specific requests only route to ZDR endpoints.
Usage
Include thezdr parameter in your provider preferences:
zdr is set to true, the request will only be routed to endpoints that have a Zero Data Retention policy. When zdr is false or not provided, ZDR enforcement still applies if enabled in your account or guardrail settings.
ZDR with BYOK Keys
By default, a BYOK key follows the same ZDR rules as OpenRouter credits. If your own provider agreement includes zero data retention, you can declare that on the key. ZDR enforcement then allows requests through that key even when the shared endpoint retains prompts. The declaration does not cover video generation. See Declaring ZDR on a Key.Caching
Some endpoints/models provide implicit caching of prompts. This keeps repeated prompt data in an in-memory cache in the provider’s datacenter, so that the repeated part of the prompt does not need to be re-processed. This can lead to considerable cost savings. OpenRouter has taken the stance that in-memory caching of prompts is not considered “retaining” data, and we therefore allow endpoints/models with implicit caching to be hit when a ZDR routing policy is in effect.ZDR for Private Deployments
A private deployment is an endpoint that connects a catalog model to a deployment you operate in your own provider account, authenticated with your BYOK key. Only organizations granted private access can route to it. OpenRouter has no view into your agreement with that upstream, so the retention classification comes from a declaration you make when you create or edit the private deployment.Declaration states
“ZDR is required” means any enforcement path described above: the account-level privacy setting, a model-group or guardrail ZDR setting, or
provider.zdr on the request.
Not declared
A private deployment does not inherit the data policy of any public endpoint or provider, even when it connects to the same upstream service. A new private deployment with no declaration uses the conservative unverified fallback described in How OpenRouter Manages Data Policies: OpenRouter treats it as retaining, so it is not eligible for any request that requires ZDR.Declared ZDR
Declaring ZDR keeps the private deployment in your organization’s ZDR routing pool. Every other routing constraint still applies: the requesting organization must hold private access to the endpoint, the endpoint must be available for the requested model, and provider preferences, guardrails, and other data-policy settings are evaluated as usual. The declaration only changes the retention classification. It does not add the private deployment to the ZDR routing pool of any organization without private access, and it does not affect the ZDR eligibility of the public endpoints for the same model.Declared non-ZDR
Declaring non-ZDR records an explicit attestation that the upstream retains data. Under a ZDR requirement it routes the same way as Not declared today. The difference is the fact preserved for your audit trail: Declared non-ZDR is known and attested, Not declared is unknown.Existing private deployments
Existing private deployments keep their current classification. Introducing this setting did not bulk-migrate them, so a private deployment created before the setting existed behaves exactly as it did. Editing its declaration applies the rules above, subject to the override precedence below.Overrides and attestationsAn explicit OpenRouter data-policy override set by our team remains authoritative over your declaration. If OpenRouter has assigned a specific data policy to your private deployment, that policy decides eligibility regardless of what you declared.A declaration is your attestation about your agreement with the upstream. OpenRouter records it and routes on it. It is not independent verification by OpenRouter of the upstream’s contractual behavior.