> ## Documentation Index
> Fetch the complete documentation index at: https://docs.requesty.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Note>
  **[Configure logging and ZDR](https://app.requesty.ai/admin-panel)** in the Requesty Console.
</Note>

## 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                                      |

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

## 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.

```mermaid theme={"dark"}
graph TD
    A[API Request] --> B{Key logging<br/>enabled?}
    B -->|No| C[Store telemetry only<br/>No prompts or responses stored]
    B -->|Yes| D{Org ZDR<br/>enabled?}
    D -->|Yes| C
    D -->|No| E[Store telemetry + payload<br/>Messages, choices, tools stored]

    style C fill:#059669,color:#fff
    style E fill:#D97706,color:#fff
```

**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.

<Tabs>
  <Tab title="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
  </Tab>

  <Tab title="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
  </Tab>

  <Tab title="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
  </Tab>
</Tabs>

### 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:

<Steps>
  <Step title="Organization flag set">
    The organization is permanently marked as ZDR-enabled. There is no disable endpoint.
  </Step>

  <Step title="All existing API keys updated">
    Every API key in the organization has logging and debugging set to `false`.
  </Step>

  <Step title="Org defaults locked">
    The organization's `default_logging` is set to `false`, so all future API keys are created with logging off.
  </Step>

  <Step title="Logging changes blocked">
    `allow_logging_change` is set to `false`. No user, including admins, can re-enable logging on any key.
  </Step>
</Steps>

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

### 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.

```mermaid theme={"dark"}
graph TD
    A[API Request arrives at Router] --> B[Router builds insight payload]
    B --> C{ZDR enabled<br/>OR logging off?}
    C -->|Yes| D[Insight contains<br/>telemetry only]
    C -->|No| E[Insight contains<br/>telemetry + payload]
    D --> F[Send to Accounting Service]
    E --> F
    F --> G{Payload fields<br/>present?}
    G -->|No| H[Ingest telemetry only<br/>No chunks written to DB]
    G -->|Yes| I[Ingest telemetry + chunks]

    style D fill:#059669,color:#fff
    style H fill:#059669,color:#fff
    style E fill:#D97706,color:#fff
    style I fill:#D97706,color:#fff
```

**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.

<Warning>
  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.
</Warning>

## 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.

<Info>
  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.
</Info>

### 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](/features/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](/features/bring-your-own-keys)           | Routes through your own provider account with your own data agreements   |

<Warning>
  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.
</Warning>

## Enterprise Plan Features

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

### Available Controls

<CardGroup cols={2}>
  <Card title="Default Logging Policy" icon="toggle-on">
    Set whether new API keys are created with logging on or off by default
  </Card>

  <Card title="Logging Change Restrictions" icon="shield-halved">
    Prevent non-admin users from toggling logging on their own API keys
  </Card>

  <Card title="Zero Data Retention" icon="lock">
    Irrevocably disable all payload logging organization-wide
  </Card>

  <Card title="Audit Logging" icon="clipboard-list">
    Full audit trail of all configuration changes, including who changed what and when
  </Card>
</CardGroup>

### 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

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Is ZDR reversible?">
    No. ZDR is intentionally irreversible to provide a compliance guarantee. If you need flexibility, use per-key logging controls instead.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>