Data Privacy & Zero Data Retention

How Requesty handles your data, how logging works, and how Zero Data Retention (ZDR) guarantees we never store or access your prompts and responses.

Requesty is designed so that your prompts and responses are never stored unless you explicitly enable logging. When logging is off, the system structurally cannot retain or display request content. Zero Data Retention (ZDR) goes further by making this guarantee irrevocable at the organization level.

Configure logging and ZDR in the Requesty Console.

What Gets Stored

Every API request produces two categories of data: telemetry (metadata about the request) and payload (the actual prompt and response content). These are handled independently.

Telemetry (always stored)

Regardless of your logging or ZDR settings, Requesty stores operational metadata for billing, analytics, and debugging:

Data	Examples
Token counts	Input tokens, output tokens, cached tokens, reasoning tokens
Cost	Provider cost, router cost
Latency	Provider latency, total latency, time to first token
Model info	Model requested, model used, provider used
Request status	Success/failure, HTTP status code, finish reason
Request metadata	Timestamp, API key ID, request ID, tags, custom extra headers
Routing info	Stream vs. non-stream, BYOK usage, deployment region

This data powers your analytics dashboards, cost tracking, and alerting. It contains no prompt or response content.

Payload (only stored when logging is enabled)

Request and response content is only stored when both of the following are true:

1. The API key has logging enabled
2. The organization does not have ZDR enabled

When payload logging is active, the following is stored:

Data	Description
Messages	Truncated request messages (system prompts, user prompts, conversation history)
Choices	Truncated response content (assistant replies)
Tools	Tool/function definitions from the request
Raw request body	Full request body stored in object storage

Even with logging enabled, message and response content is truncated before storage. Full raw request bodies are stored separately in encrypted object storage.

Logging Controls

Logging is controlled at two levels: per-API-key and per-organization.

Per-API-Key Logging

Each API key has a logging boolean that determines whether payload data is captured for requests made with that key.

Default behavior: New API keys inherit the organization’s default_logging setting. Admins can toggle logging on individual keys at any time (unless restricted by organization policy).

Organization Logging Policy

Organization admins can configure two settings that govern logging behavior across all API keys:

Setting	Effect
Default Logging	Whether newly created API keys start with logging on or off
Allow Logging Change	Whether non-admin users can toggle logging on their own API keys

These settings are available under Admin Panel > Settings for organizations on the Enterprise plan.

Default Configuration

Suitable for most teams:

• default_logging = true: New keys log by default for observability
• allow_logging_change = true: Users can turn logging off on keys handling sensitive data

Privacy-First Configuration

For teams handling sensitive data:

• default_logging = false: New keys start with logging off
• allow_logging_change = true: Users can opt-in to logging when needed

Enterprise Lockdown

For regulated environments:

• default_logging = false: No payload logging by default
• allow_logging_change = false: Non-admin users cannot enable logging
• Admins retain the ability to toggle logging on individual keys

Who Can Change Logging

Actor	Allow Logging Change = On	Allow Logging Change = Off	ZDR Enabled
Admin	Can toggle any key	Can toggle any key	Blocked
Non-admin user	Can toggle own keys	Blocked by org policy	Blocked
API key creation	Uses org default	Uses org default	Forced off

Zero Data Retention (ZDR)

ZDR is an organization-level compliance mode that provides a hard guarantee: no request or response content is ever stored, and this cannot be reversed.

What ZDR Does

When an admin enables ZDR, four things happen atomically:

1. Organization flag set

   The organization is permanently marked as ZDR-enabled. There is no disable endpoint.

2. All existing API keys updated

   Every API key in the organization has logging and debugging set to false.

3. Org defaults locked

   The organization’s default_logging is set to false, so all future API keys are created with logging off.

4. Logging changes blocked

   allow_logging_change is set to false. No user, including admins, can re-enable logging on any key.

ZDR is a one-way operation. Once enabled, it cannot be disabled. This is by design to provide an irrevocable compliance guarantee.

ZDR vs. Logging Off

Capability	Logging Off (per key)	ZDR (organization-wide)
Prevents payload storage	Yes, for that key	Yes, for all keys
Reversible	Yes, admin can re-enable	No, permanent
Applies to new keys	Only if org default is off	Automatically
Admin can override	Yes	No
Blocks config changes	No	Yes, logging and related settings locked

How ZDR Is Enforced

ZDR enforcement happens at multiple independent layers, so even a bug in one layer cannot cause data leakage.

Layer 1: Router (data plane) The router checks both the ZDR flag and the API key’s logging setting before attaching any payload data to the insight. If either condition blocks logging, the messages, choices, and tools fields are never populated. They are not sent to any downstream service.

Layer 2: Raw request storage Full request bodies are only sent to encrypted object storage when the API key has logging enabled. Since ZDR forces logging off on all keys, raw request bodies are never stored.

Layer 3: Accounting service (control plane) The accounting service receives insights from the router. When payload fields are absent (as they always are under ZDR), the service takes a telemetry-only ingestion path. No message content reaches the database.

Layer 4: Configuration lockdown ZDR prevents re-enabling logging at every level: individual API key updates, organization config changes, and new API key creation. The API returns 403 Forbidden for any attempt to enable logging on a ZDR organization.

What This Means in Practice

With ZDR enabled:

• Requesty cannot see your prompts or responses. The data is never attached to internal messages, never written to any database, and never stored in object storage.
• Your analytics still work. Token counts, costs, latency, model usage, error rates, and all operational metrics continue to function normally.
• Audit trail is maintained. All ZDR and logging configuration changes are recorded in your organization’s audit log.
• Debug logs excluded. ZDR also disables the debug flag on all API keys, which prevents request/response bodies from appearing in application logs.

Enabling ZDR

ZDR can only be enabled by an organization admin.

1. Navigate to Admin Panel in the Requesty Console
2. Locate the Zero Data Retention section
3. Enable ZDR

Once confirmed, the change takes effect immediately across all existing and future API keys.

Before enabling ZDR, ensure your team does not depend on message logging for debugging or compliance review. Once enabled, historical logs with payload content remain, but no new payload data will be captured.

Provider-Side Data Policies

ZDR and logging controls govern what Requesty stores. Your requests still travel to the upstream LLM provider (OpenAI, Anthropic, Google, AWS Bedrock, etc.), and each provider has its own data retention and training policies. To achieve end-to-end data privacy, you need to consider both layers.

How Requesty Helps You Choose

Every model in the Requesty catalog is tagged with provider-level data policy metadata:

Field	Meaning
Data Retention	Whether the provider retains your request/response data after inference
Data Used for Training	Whether the provider may use your data to train or improve their models
Privacy Comments	Additional provider-specific notes on data handling

These fields are visible in the Model Library, on individual model cards, and in the Approved Models admin panel. Models tagged “Zero retention” and “Not for training” are highlighted in green.

Filtering by Data Policy

Use the Data Policy filter in the Approved Models panel to restrict your organization to providers that match your compliance requirements:

• Data Retention = No: Only show models where the provider does not retain your data
• Data Used for Training = No: Only show models where the provider does not use your data for training

Quick Start Presets

The Approved Models panel offers one-click presets for common compliance configurations:

Preset	What It Approves
EU Only	Models hosted in EU regions
EU + ZDR	EU-hosted models with no data retention and no training
US Only	Models hosted in US regions
ZDR Only	Models with no data retention and no training, any region

These presets filter and pre-select matching models. Review the selection and confirm to apply.

Enabling Requesty’s ZDR mode does not automatically restrict your approved models to zero-retention providers. These are independent controls. ZDR prevents Requesty from storing payloads. Approved Models controls which providers your team can send requests to. For maximum data privacy, enable ZDR and restrict approved models to zero-retention providers.

Layered Privacy Strategy

For organizations with strict data handling requirements, combine multiple controls:

Layer	Control	What It Protects
Requesty storage	ZDR or per-key logging off	Prevents Requesty from storing prompts/responses
Provider selection	Approved Models with data policy filters	Ensures requests only go to providers with compatible retention policies
Data residency	EU routing endpoint	Keeps Requesty processing and storage in the EU
Provider residency	EU-region models (e.g. bedrock/@eu-central-1)	Keeps model inference in the EU
Credential isolation	BYOK	Routes through your own provider account with your own data agreements

BYOK (Bring Your Own Key) routes requests through your own provider account, which means the provider’s data policies for your account apply. This is useful when you have a custom data processing agreement (DPA) or BAA with the provider that offers stronger guarantees than their default API terms.

Enterprise Plan Features

Organizations on the Enterprise plan have additional configuration options for fine-grained control over data handling.

Available Controls

Default Logging Policy

Set whether new API keys are created with logging on or off by default

Logging Change Restrictions

Prevent non-admin users from toggling logging on their own API keys

Zero Data Retention

Irrevocably disable all payload logging organization-wide

Audit Logging

Full audit trail of all configuration changes, including who changed what and when

Compliance Matrix

Requirement	How Requesty Addresses It
No prompt/response storage (Requesty)	ZDR mode or per-key logging off
No provider-side data retention	Approved Models filtered by data policy
No training on your data	Approved Models filtered by training policy
EU data residency	EU routing endpoint (router.eu.requesty.ai) + EU-region models
Access control	RBAC with admin/user roles
Audit trail	Audit logs for all config changes
Data isolation	Per-API-key and per-group data scoping
Encryption at rest	All stored data encrypted using AES-256
Encryption in transit	TLS 1.2+ on all endpoints
Custom provider agreements	BYOK with your own DPA/BAA

FAQ

Can Requesty employees see my prompts?

No. When logging is off or ZDR is enabled, prompt and response content is never stored. There is no data to access. When logging is on, payload data is stored in your organization’s encrypted storage, accessible only through your API keys and the Requesty Console with appropriate RBAC permissions.

What happens to existing logs when I enable ZDR?

ZDR applies to new requests only. Historical log entries with payload content remain accessible. ZDR prevents any new payload data from being captured going forward.

Can I enable ZDR for specific API keys instead of the whole organization?

ZDR is organization-wide. For per-key control, toggle logging off on individual API keys. This achieves the same result (no payload storage) but is reversible and key-specific.

Does disabling logging affect my analytics?

No. Token counts, costs, latency, model usage, and all operational metrics are always captured regardless of logging settings. Only prompt/response content is affected.

Is ZDR reversible?

No. ZDR is intentionally irreversible to provide a compliance guarantee. If you need flexibility, use per-key logging controls instead.

How do I verify ZDR is working?

After enabling ZDR, check the Logs view for any new request. You will see telemetry data (tokens, cost, latency, model) but the Messages tab will show no content. This confirms payload data is not being captured.

Does ZDR prevent the LLM provider from seeing my data?

No. ZDR controls what Requesty stores. Your prompts and responses still travel to the LLM provider for inference. To control provider-side data handling, use the Approved Models data policy filters to restrict your organization to zero-retention, no-training providers. For the strongest guarantee, use BYOK with a custom data processing agreement with your provider.

Does enabling ZDR automatically restrict which models I can use?

No. ZDR and Approved Models are independent controls. ZDR governs Requesty-side storage. Approved Models governs which providers your team can send requests to. For end-to-end privacy, enable ZDR and restrict approved models to zero-retention providers using the data policy filter or the “ZDR Only” quick-start preset.