For the complete documentation index, see llms.txt. This page is also available as Markdown.

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>:zdr

For example:

Standard slug
ZDR slug

deepseek/deepseek-v4.1-flash

deepseek/deepseek-v4.1-flash:zdr

With the suffix in place, FastRouter:

  1. Filters the model's available providers down to ZDR-compliant providers only.

  2. Routes the request among those providers using your normal routing preferences (for example, provider.sort).

  3. 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:

Provider

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:

Feature
Why data 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:

  1. Use the :zdr slug so only ZDR providers serve your requests.

  2. Use an API key with content logging disabled.

  3. 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.only list (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