Zero Data Retention

ZDR is a contractual guarantee from the model provider: the request and response are not stored in any form (logs, telemetry, cache, fine-tuning). Geek Hub maintains a list of endpoints where this guarantee is signed and verified, and rejects ZDR-marked requests targeting endpoints outside the list.

Three activation levels

Per request

Pass zdr: true in your body. The gateway checks the target model against the registry. Verified → proceed. Not verified → HTTP 422 with reason.

Per account

In /dashboard/settings → Zero Data Retention enable ZDR per provider group (Anthropic, OpenAI, Google, Others). When a group is on, all org requests to that group are checked.

Per guardrail

Guardrails let you configure ZDR per user or per API key. Useful when different teams under the same org need different policies.

Example request

curl -X POST https://api.geekhub.mx/v1/chat/completions \
  -H "Authorization: Bearer ghub_sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-4-6",
    "messages": [{"role":"user","content":"Hi"}],
    "zdr": true
  }'

Verified endpoints

Group	Models	Verified
Anthropic	claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5	3 / 3
OpenAI	gpt-5, gpt-4.1, gpt-4.1-mini, o4-mini, tts-1, tts-1-hd, gpt-4o-mini-tts	7 / 7
Google	gemini-2.5-pro, gemini-2.5-flash	2 / 2
Others (DeepSeek, xAI, Moonshot, fal)	—	0 / 8

Rejection format

{
  "error": {
    "type": "zdr_not_verified",
    "message": "Provider does not offer a signed ZDR policy verified by Geek Hub.",
    "model": "deepseek/deepseek-v4-flash",
    "verified_alternatives": ["openai/gpt-5", "anthropic/claude-sonnet-4-6"]
  }
}

ZDR is part of your GDPR art. 5(1)(e) (storage limitation) compliance posture. If your provider doesn’t retain the conversation, retention at that layer is effectively zero — reducing the scope of your upstream processing obligations.

ZDR covers the model provider’s retention. Geek Hub does store billing metadata (model id, tokens, cost, latency) for CFDI/Stripe. Message content is not persisted at the gateway layer.

What we persist vs what we don’t

No ambiguity — this is how we separate content (prompt/response) from metadata (billing and audit):

Data type	ZDR on	Persisted	Where	Retention
Message text (user/assistant/system)	Yes	❌ No (request memory only)	—	0
Prompt images	Yes	❌ No	—	0
Generated images/videos (output)	Yes	✅ Yes (so you can download them)	Supabase Storage	Account lifetime or upon request
Input and output token counts	Always	✅ Yes	Postgres `requests`	7 years (SAT tax obligation)
Model, provider, request_id, timestamp	Always	✅ Yes	Postgres `requests`	7 years
Cost USD/MXN per request	Always	✅ Yes	Postgres `requests`	7 years
Provider error codes	Always	✅ Yes (code only, not content)	Postgres `requests`	90 days
Gateway technical logs (HTTP status, latency)	Always	✅ Yes	stderr → aggregator	30 days

Hard rule: anything stored in requests is numeric or identifier metadata. We never store the content of messages[] nor the prompt from /images, /videos, /audio, not even hashed, not even with ZDR off. If you need to retain conversations yourself, use a request.completed webhook to your own backend (see Webhooks).

Get started

Concepts

Advanced features

Legal & compliance

API Reference

Models

Zero Data Retention

Three activation levels

Example request

Verified endpoints

Rejection format

What we persist vs what we don’t

​Three activation levels

​Example request

​Verified endpoints

​Rejection format

​GDPR — art. 5(1)(e) data minimization

​What we persist vs what we don’t

Three activation levels

Example request

Verified endpoints

Rejection format

GDPR — art. 5(1)(e) data minimization

What we persist vs what we don’t