Overview
Zero Data Retention (ZDR) and request logging are key-level data retention controls that determine how your data flows through the system.- ZDR restricts routing to only providers with certified zero data retention policies — your prompts and completions are never stored by the upstream provider.
- Request logging controls whether Concentrate stores your request and response content for conversation history and audit purposes.
ZDR and logging are key-level settings, not request-body parameters. Configure them once on an API key and use that key normally with any of our inference endpoints.
Configure in Dashboard
Key-Level Settings
- Go to API Keys
- Create or edit a key
- Under Data Retention, configure:
- Zero Data Retention (Providers) — when enabled, only ZDR-certified providers are used
- Enable Request Logging — when enabled, full request/response content is stored (encrypted) for conversation history
Organization-Level Enforcement
Organization admins can enforce data retention policies across all keys in the organization:- Go to Organization Settings
- Under Data Retention, toggle enforcement for ZDR and/or logging
- Enforced settings lock the corresponding toggle on all keys in the organization
Enforcement Hierarchy
Data retention policies cascade from the highest organizational level down to individual keys:
Each field (
zdr and logging) is resolved independently. A key tracks which level set each policy via a policy_source field ("org", "team", "user", or "key").
When a higher level releases enforcement, keys revert to their own settings unless another enforcer still applies.
How ZDR Affects Routing
When ZDR is enabled on a key, the routing system only considers providers whose models have a certified ZDR policy. Non-ZDR providers are excluded entirely — even if they would otherwise be the best match for cost, latency, or performance.422 error rather than falling back to a non-ZDR provider:
ZDR enforcement is strict by design. The system will never silently route to a non-ZDR provider, even as a fallback.
ZDR-Supported Providers
ZDR is a property of the (model, provider) pair, not of a model or its author alone. The native model detail endpoint exposes a per-providerzdr field that is either false or an object with policy and certificate URLs:
zdr field is an object. The combined GET /v1/models response does not include this field — use GET /v1/models/{id} to inspect per-provider ZDR status, or refer to the table below.
The following provider slugs currently offer ZDR-certified endpoints on Concentrate:
A model’s ZDR providers frequently do not include the model’s own author. For example, Llama models reach ZDR via Bedrock, GLM models via DeepInfra/Novita/Azure Foundry, and Qwen models via Bedrock.
Gemini models are ZDR-certified only through the Vertex provider (Google’s ZDR policy) — the
ai-studio provider does not offer ZDR. A Gemini request is only actually zero-data-retention if ZDR is enabled on the API key making the request; with ZDR enabled, routing is restricted to Vertex, and without it Gemini requests may route to non-ZDR providers.ZDR-Supported Models
103 models across 9 providers are routed through ZDR-certified endpoints. The table below lists each model and the specific provider slug(s) you can pin to guarantee a ZDR-certified path. When ZDR is enabled on a key, Concentrate filters routing to these providers automatically.OpenAI (26)
Anthropic (11)
Google (13)
Gemini models reach ZDR via the
vertex provider only — see the Google tab of Supported Models for the current per-model breakdown.
Meta (7)
Mistral (5)
Alibaba Cloud (6)
DeepSeek (5)
z.ai (5)
Amazon (5)
Moonshot AI (4)
MiniMax (4)
xAI (1)
Writer (2)
AI21 Labs (2)
NVIDIA (2)
Xiaomi (2)
StepFun AI (2)
Tencent (1)
This list is generated from the live
/v1/models/{id} catalog. Use the List Models endpoint to verify in real time — only providers whose zdr field is an object (not false) qualify.How Logging Works
Request logging controls whether your request and response content is persisted by Concentrate.When Logging is Enabled
- Full request body and response body are encrypted and stored
- Conversation history is available in the dashboard
- Redaction summaries (if guardrails are active) are stored alongside the encrypted content
When Logging is Disabled (Default)
- Request and response content is not stored — the
requestandresponsefields are set tonullbefore persistence - Redaction data is also stripped
- Basic request metadata (status code, elapsed time, model, provider) is still logged for operational purposes
- Token usage and cost are still tracked for billing
Logging is disabled by default. New keys start with logging disabled, following a privacy-first approach.
What Is Always Logged
Regardless of the logging setting, the following metadata is always recorded:
This metadata does not include your prompt content or model responses.
Defaults
Keys created before the data retention feature was introduced use the same safe defaults.
Best Practices
Use ZDR for regulated workloads
Use ZDR for regulated workloads
Enable ZDR on keys used for healthcare, financial, or other regulated data. This guarantees upstream providers will not retain your data, backed by their certified policies.
Enable logging for debugging
Enable logging for debugging
Turn on logging during development or when debugging issues. You can view full request/response history in the dashboard. Disable it in production if you don’t need conversation history.
Enforce at the org level for compliance
Enforce at the org level for compliance
If your organization requires ZDR across all workloads, enforce it at the organization level. This locks the setting on every key and prevents individual users from disabling it.
Combine ZDR with provider restrictions
Combine ZDR with provider restrictions
For maximum control, combine ZDR with the
routing.provider.fallbacks parameter to limit requests to a specific set of approved, ZDR-certified providers:Check model ZDR support before pinning
Check model ZDR support before pinning
Before pinning a specific model with ZDR enabled, verify it has ZDR-certified providers available. Use the List Models endpoint to check the
zdr field.Related Documentation
Routing
How routing selects providers and handles ZDR filtering
Guardrails & Redaction
API-key level redaction for input/output safety
List Models
Check ZDR support on available models
Error Handling
Handle ZDR-related 422 errors