Zero Data Retention

Zero data retention (ZDR) is an arrangement that limits a model provider's storage of request and response content for eligible endpoints and capabilities, subject to the agreement's exceptions. It usually requires an agreement or account-level approval rather than an API flag, and coverage depends on the endpoint and features used.

Why the default is not zero

Providers usually keep content for a period for abuse monitoring and policy enforcement. OpenAI's documentation, for example, says abuse-monitoring logs are generated for API usage and kept for up to 30 days by default unless legal requirements or service protection require longer, and that these logs hold prompts, responses and derived metadata. Retention is therefore a standing property of the vendor relationship, separate from whether the data is used for training. Windows and terms differ by provider, product tier and region, and change over time.

What ZDR typically changes

Under OpenAI's ZDR, customer content is excluded from abuse-monitoring logs, subject to the documented exceptions. For /v1/responses and /v1/chat/completions, store is treated as false even if the caller enables it. Other endpoints and capabilities may still retain application state.

What remains

ZDR narrows one copy of the data. A request creates others, and many are in your control:

• Application state. Features such as threads, uploaded files and vector stores can retain data when they are not ZDR-eligible. Stateless calls avoid explicit conversation storage, but do not remove every form of application state: feature-specific processing or caching can have separate retention rules.
• Special categories. The same documentation says some flagged content, such as certain images, can be retained for review regardless of settings.
• Metadata. Request timing, token counts, identifiers and billing records are generally outside what the content guarantee covers.
• Your own copies. Request logs, traces, caches, conversation stores, analytics, error trackers, and test sets sampled from traffic hold the same text. A deletion or retention promise to users must cover them.
• Downstream services. Search tools, plugins, embeddings and hosted tools may be separate services with separate terms.
• Legal holds. Providers may be required to preserve data under a legal order, regardless of the agreement.

How to check

1. Read the agreement and the provider's data-retention page for each endpoint and feature you use; coverage is often per endpoint.
2. Inventory where each type of content goes, including every vendor in the path, and write down the retention for each.
3. Test it. Make a request with a unique marker string, then check that the retrieval or listing endpoints return nothing for it, and review your own logs for the marker. A test can show your own copies exist; it cannot show what the provider holds internally, so the contract carries that part.
4. Keep raw content out of logs by default. Store ids, versions, counts and hashes; keep raw text only where retention rules allow it.
5. Minimize what is sent: ZDR limits storage but not exposure during processing.

Related ideas

Data minimization reduces what exists to retain. Redaction before the call keeps sensitive values from reaching the provider at all, and a pseudonym kept with a keyed hash (HMAC) lets you join records without raw identifiers. Deletion requests and retention schedules apply to the copies you hold.

References

• OpenAI, Data controls in the OpenAI platform