# Data handling and residency

> Where requests are processed, what is stored and for how long, the fallback exception, roles under the GDPR and security basics.

Dex processes every request in the EU, and by default it stores no request content at all. It keeps request metadata for 30 days and billing records for 7 years. Customer content is never used to train, tune or calibrate a model.

## Where data is processed

| Part | Where |
| --- | --- |
| Gateway, database, cache, secrets and logs | Microsoft Azure, West Europe region (the Netherlands) |
| Dex inference nodes | Dedicated hardware operated by thinQit in the Netherlands |
| Fallback | Azure OpenAI in the EU data zone (Data Zone Standard), with its account in West Europe, or Sweden Central if West Europe lacks the model |
| Payments | Stripe, through Stripe Payments Europe in Ireland. Stripe processes payment data only, never request content. |

The full list of third parties is on the [subprocessors page](/legal/subprocessors/).

## No content stored by default

Your state, questions, labels and answers exist only in memory while the request runs: in the gateway, on the GPU worker, in the relay between gateway replicas (an in-memory store with persistence turned off) and, when used, in the fallback call.

- They are never written to disk, logs, traces, metrics or error reports.
- Logs and traces are built from an allow-list of fields, so a field that carries content cannot be logged by accident.
- The GPU worker holds content in GPU and host memory only while the job runs.
- Responses are not cached across requests.
- The console playground does not store content either.

Support asks for a request id, never for request content.

## What we keep, and for how long

**Request metadata, 30 days.** For each request:

- the request id, timestamps, account id and key id;
- the model and `served_by`;
- token counts and the charge;
- the latency breakdown, status and error code;
- the number of questions of each type;
- the SDK name and version from `user-agent`;
- your `x-client-request-id`, if you sent one;
- the client IP address, truncated to /24 for IPv4 or /48 for IPv6.

**Billing records, 7 years.** Usage totals per minute, ledger entries, top-ups and invoices, as Dutch tax law requires.

**Idempotency records, 24 hours.** A fingerprint of the request and its outcome, never its content. See [Idempotency](/docs/reference/idempotency/#what-happens-to-the-key).

## Opt-in content logging

Content logging is off unless the account owner turns it on. It helps when you debug an integration.

- The owner turns it on in the console, separately for live and test keys, with a retention of 1 to 30 days (7 by default).
- Logged requests and responses are encrypted with a data key for your account, which is itself protected by a key in Azure Key Vault, and stored in Azure Blob storage in the EU.
- They are deleted automatically when the retention period ends.
- The console shows them for debugging.
- Turning logging off deletes the existing logs within 1 hour.

## No training on customer data

Customer content is never used to train, tune or calibrate any model. Calibration uses our own decision sets. See [Calibration](/docs/concepts/calibration/#data-and-reference-labels).

## Azure OpenAI abuse monitoring

This exception applies only to requests served by the fallback.

By default, Azure OpenAI abuse monitoring may store prompts that its classifiers flag, for up to 30 days, inside the EU data zone. Before launch we apply to Microsoft for modified abuse monitoring. Until Microsoft approves it, the exception applies, and the data processing agreement states it too.

To avoid it, keep your requests on the GPU path: send `"fallback": "never"`, or pin an exact model version. See [Fallback and served_by](/docs/concepts/fallback/#keeping-a-request-on-the-gpu).

## Roles

- **Request content:** you are the controller, and Thinqit B.V. is the processor, under the [data processing agreement](/legal/dpa/).
- **Account and billing data:** Thinqit B.V. is the controller. See the [privacy policy](/legal/privacy/).

The legal documents are drafts until counsel review is complete.

## Security

- **Transport.** HTTPS only, with TLS 1.2 or newer.
- **API keys.** A key is `dex_live_` or `dex_test_` followed by 40 characters: 34 random characters and a 6-character checksum, so secret scanners can check the format offline. We store only a SHA-256 hash of the key and a short display prefix, and show the full key once, when you create it.
- **Scopes and expiry.** Keys have scopes (`decide`, `usage:read`, `balance:read`), an optional expiry date and optional limits at or below your account's caps.
- **Revocation.** Revoking a key takes effect across every gateway replica within 1 second.
- **Leaked keys.** Before launch we register the key format with GitHub secret scanning, so a key pushed to a public repository is revoked automatically and its owner is emailed.
- **Prompt injection.** Instructions written inside the state can still steer answers. Add the guardrail question from [Known limits](/docs/concepts/known-limits/#instructions-inside-the-state-can-steer-answers) and route on it when the state holds text from others.
- **Console.** Sign-in is by a one-time email code. The session cookie is HttpOnly, Secure and SameSite=Lax, and every console action that changes something needs a CSRF token.
- **Secrets and network.** Our own secrets live in Azure Key Vault, and services reach the database with managed identities, so there is no database password. The database and cache accept private network traffic only, and Dex's inference nodes accept no inbound connections.