Zero Data Retention
FastRouter lets you restrict any request to Zero Data Retention (ZDR) providers by adding the :zdr suffix to the model slug.
Introduction
Some workloads can't have prompts or completions stored by a model provider, not even temporarily for logging, abuse monitoring, or training. FastRouter lets you restrict any request to Zero Data Retention (ZDR) providers by adding the :zdr suffix to the model slug.
When you use :zdr, FastRouter routes your request only to providers whose settings and terms indicate zero data retention for your request and response data. If no ZDR provider can serve the model, the request fails instead of falling back to another provider.
How it works
Append :zdr to any model ID:
<provider>/<model>:zdrFor example:
deepseek/deepseek-v4.1-flash
deepseek/deepseek-v4.1-flash:zdr
With the suffix in place, FastRouter:
Filters the model's available providers down to ZDR-compliant providers only.
Routes the request among those providers using your normal routing preferences (for example,
provider.sort).Returns an error if no ZDR-compliant provider is available for that model after all filters are applied.
No other changes to your request are needed. The request and response formats are identical to a standard chat completion.
Supported providers
The following providers are currently treated as Zero Data Retention providers on FastRouter:
Fireworks
Baseten
Groq
Perplexity
DeepInfra
Together
A model can be used with :zdr only if at least one of these providers serves it on FastRouter.
What ZDR does not cover
:zdr applies only to the choice of model provider, routing your request to providers whose settings and terms indicate zero data retention. It doesn't turn off FastRouter features that need to store or pass along your prompts to work. If you use any of the following on a :zdr request, your prompts (and in some cases responses) can be stored:
Plugins such as PDF processing
The plugin processes your file or prompt content as part of handling the request.
Web search tool / :online
Your query is sent to a search service to fetch results, outside the ZDR provider.
Responses API with preserved state
Keeping conversation state across requests requires storing earlier prompts and responses.
FastRouter response caching
Prompts and responses are stored so that matching future requests can be served from the cache.
If you want to minimize data retention, avoid these features on requests that carry sensitive data.
Disabling content logging on FastRouter
Separately from provider retention, FastRouter can log prompt and response content for your requests. You can disable content logging at the API key level to turn off prompt and response logging for all requests made with that key.
To reduce how much of your data is retained, you can combine these:
Use the
:zdrslug so only ZDR providers serve your requests.Use an API key with content logging disabled.
Avoid the features listed above.
Example request
Example response
The usage.provider field tells you which provider served the request. For a :zdr request, this will always be one of the supported ZDR providers listed above. In this example, the request was served by DeepInfra.
Combining :zdr with provider routing
:zdr works alongside the provider object. ZDR filtering is applied first, and your provider preferences are then applied to the remaining ZDR providers.
For example, to route to the highest-throughput ZDR provider:
If you use provider.only to pin specific providers, include only ZDR providers. If none of the providers left after filtering are ZDR-compliant, the request is rejected.
Error handling
If no ZDR-compliant provider can serve the request, FastRouter returns an error rather than routing to a non-ZDR provider.
Example: no ZDR provider available
Request:
Response:
Here, provider.only limits routing to a provider that isn't ZDR-compliant, so no eligible provider is left.
This error can occur when:
The model isn't served by any of the supported ZDR providers.
Your
provider.onlylist (or other provider filters) excludes every ZDR provider serving the model.The model ID itself is invalid.
To resolve it, remove or adjust the conflicting provider filters, choose a model served by at least one ZDR provider, or check the model ID for typos.
FAQ
Does :zdr change the response format? No. Requests and responses follow the standard chat completions format. The only visible difference is that usage.provider will always be a ZDR provider.
Will FastRouter ever fall back to a non-ZDR provider? No. When :zdr is set, requests are routed only to ZDR-compliant providers. If none are available, the request fails with an error.
How do I confirm which provider handled my request? Check the usage.provider field in the response.
Does :zdr mean my prompts are never stored anywhere? No. :zdr affects only which model provider is selected, based on that provider's settings and terms. Plugins such as PDF processing, the web search tool / :online, stateful Responses API usage, and FastRouter response caching can store prompts.
Can I use :zdr with every model? Only with models served by at least one supported ZDR provider. For other models, the request returns the error shown above.
Last updated
