Zero data retention
A model can be served by more than one provider, and each provider has its own terms for the content you send. ModelRelay publishes those terms per route (model × provider) and can hold a request to the routes whose provider keeps no request content. That is zero data retention (ZDR).
Find ZDR routes
Every route on List Models carries a data_policy: whether the provider retains request content and for how long, whether it trains on it, and the provider statement those values come from. A route is ZDR when data_policy.zdr is true, which is exactly when retention is none. unknown means no first-party statement settles the question, and counts as neither ZDR nor excluded from training.
On the models page, the ZDR filter keeps models with at least one ZDR route, and each model’s page lists the data policy of every route that serves it.
Require it
There are three places to require ZDR. They combine: whichever sets it applies, and nothing a request says can remove it.
| Scope | How | Applies to |
|---|---|---|
| Request | provider.zdr: true on /v1/chat/completions, /v1/responses, or /v1/messages |
That request |
| API key | require_zdr: true on POST /api/v1/api-keys, mrl keys create --require-zdr, or the dashboard’s key form |
Every request made with the key. Fixed at creation. |
| Account | PUT /api/v1/account/data-policy (Account API), mrl account data-policy set --require-zdr, or the dashboard’s account page |
Every request in the account, from any API key or customer token, from the next request on |
The compatible endpoints also accept provider.data_collection: "deny", which admits only routes whose data_policy.training is no. It has no key or account form.
A request under ZDR is served only by a route that satisfies it. It is never served elsewhere: not when no route qualifies, and not when the qualifying routes are unavailable. A model with no ZDR route fails with 400, naming whatever required it:
no route for model "<model>" satisfies require_zdr on this API key
When several sources apply, the message lists each, for example provider.zdr and require_zdr on this account. A request pinned to one provider with the native provider field, on the Responses or Images API, fails the same way when that provider’s route does not qualify:
provider "<provider>"'s route for model "<model>" does not satisfy require_zdr on this API key
The requirement applies on every surface that picks a route, including images, audio, decisions, and image-generation tool calls made during a response.
What ZDR turns off
ZDR covers ModelRelay’s own hop as well as the provider’s. A request under it is refused with 400 when it asks ModelRelay to store content:
| Feature | Stores |
|---|---|
response_cache |
The completed response, for its TTL |
state_id |
Provider state kept between calls, such as tool artifacts |
Image response_format: "url" |
The generated image, in ModelRelay’s image storage |
| Execution grants | The run’s artifacts and transcripts |
The refusal names the feature and the source of the requirement:
response_cache stores request or response content with ModelRelay, which zero data retention forbids (required by provider.zdr)
Under ZDR an image request that names no response_format returns b64_json.
ZDR does not change the request metadata ModelRelay records for billing and usage, such as timestamps, endpoints, response codes, token counts, and cost; see the Privacy Policy.
A key with require_zdr cannot mint customer tokens, since requests made with the token would not carry the key’s requirement. The account’s setting has no such limit: it binds customer tokens directly.