Skip to main content

Documentation Index

Fetch the complete documentation index at: https://concentrate.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
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:
LevelScopeCan enforce on
OrganizationAll keys in the orgTeams, users, and their keys
TeamAll keys owned by team membersTeam member keys
UserAll keys owned by the userUser’s own keys
KeySingle keyOnly itself (if not locked by a higher level)
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. 
Request with ZDR key
  → Routing filters to ZDR-certified providers only
  → Selects best provider from that subset
  → Returns response
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: 
{
  "error": {
    "type": "invalid_request_error",
    "message": "Zero Data Retention (ZDR) is enabled, but there are no available providers or models that support it for this request."
  }
}
ZDR enforcement is strict by design. The system will never silently route to a non-ZDR provider, even as a fallback.

​
ZDR-Supported Providers

Models that support ZDR include a zdr field with links to the provider’s data retention policy and certification: 
{
  "zdr": {
    "policy_url": "https://provider.example/data-policy",
    "certificate_url": "https://provider.example/zdr-cert"
  }
}
Use the List Models endpoint to check which models support ZDR. Models without ZDR support have "zdr": false.

​
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:
FieldPurpose
API key referenceRequest attribution
URL and status codeOperational monitoring
Elapsed timePerformance tracking
Model and providerRouting analytics
Token usage (input/output)Billing
Cost (USD)Billing
This metadata does not include your prompt content or model responses.

​
Defaults

SettingDefaultNotes
ZDRDisabledAll providers available for routing
LoggingDisabledNo request/response content stored
EnforcementNoneNo org/team/user level enforcement
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.providers parameter to limit requests to a specific set of approved, ZDR-certified providers:
{
  "model": "gpt-4o",
  "input": "Process sensitive data",
  "routing": {
    "providers": ["azure"]
  }
}
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