Skip to main content

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.
Both settings are configured per API key in the dashboard and enforced automatically on every request.
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

  1. Go to API Keys
  2. Create or edit a key
  3. 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:
  1. Go to Organization Settings
  2. Under Data Retention, toggle enforcement for ZDR and/or logging
  3. Enforced settings lock the corresponding toggle on all keys in the organization
When a setting is enforced at the organization level, individual users cannot override it on their keys. The toggle appears locked in the dashboard.

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.
If no ZDR-certified provider supports the requested model or features, the API returns a 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-provider zdr field that is either false or an object with policy and certificate URLs:
A model supports ZDR only through the specific provider slug(s) whose 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 request and response fields are set to null before 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

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.
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.
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.
For maximum control, combine ZDR with the routing.provider.fallbacks parameter to limit requests to a specific set of approved, ZDR-certified providers:
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.

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