Data Policy

This page describes what deeprelay does with the data you send to the serverless inference API: what we record, what we deliberately do not record, where your requests physically go, and how long the records we do keep stick around.

It is a description of how the platform behaves today, not a contract — the Terms and Privacy Policy govern. Where the two disagree, they win and this page is a bug.

The short version

Zero data retention	Yes, on the inference API (except web search, see below). We don't store your prompts or outputs, and every upstream model provider we route to does so under a zero-data-retention agreement with us.
Training on your data	Never, by us or by any upstream model provider. The search provider behind the web search tool may use search queries and results, de-identified, to improve its models (see below).
Per-request metadata	Kept. It is your bill. Visible in your request log for 90 days.
Where requests run	US by default; some models are served from partner infrastructure in other jurisdictions. See Model routing.

Zero data retention

Your request content exists only while the request is being served. deeprelay processes it in memory, relays it to the model and streams the result back to you; when the request ends, it is gone. Every upstream model provider that serves deeprelay traffic does so under a zero-data-retention agreement with us (except web search, see below): they process your request to generate the response and do not store it or train on it.

Web search exception

The web search tool (see Web search) is the one place where request content goes to a provider that is not under a zero-data-retention agreement with us.

Web search sends the search query the model writes to our search subprocessor. Under that provider's standard terms the query and results may be retained and used to improve its models, de-identified from individuals. We have not yet enabled zero data retention for search. Your other model traffic is not sent to it.

The query is written by the model from your conversation, so it can contain content from your prompts. Only the query is sent: not your messages, files, tool definitions or keys. Nothing is searched unless your request declares the search tool (and, in Codex, unless you turned live web search on), so leaving the tool out keeps every request within zero data retention. deeprelay itself does not store the queries or the results, and logs only how many searches ran. The provider is listed on our subprocessors page.

What we do not store

For every inference endpoint (/v1/chat/completions, /v1/messages, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/videos), none of the following is written to our databases, caches, logs, error reports or traces:

• Prompts and messages, including system prompts and conversation history
• Model outputs: completions, reasoning, and refusals
• Tools: tool and function definitions, tool-call arguments and tool results
• Images you send as input (we pass image URLs and data through to the model and never fetch or keep them)
• Embedding inputs and the vectors we return
• Video prompts after the job finishes (see Video jobs)
• Request and response bodies in any access log, error log or crash report
• Server-side conversation state: /v1/responses is stateless, so there is no store / previous_response_id history held for you

The practical consequence: we cannot show you your old prompts, and neither can our support team. If you need a transcript, keep it on your side.

The short windows where content is held

Two features need to hold content briefly to work. Both are bounded and cleaned up automatically:

• Video jobs. Video generation is asynchronous, so the job holds your prompt until it finishes, because the job needs it to run. The prompt is removed from the job within 15 minutes of it finishing. The generated video is available to download for 24 hours; after that the API no longer serves it, and our storage's lifecycle rule deletes the file within about 3 days of its creation. A failure reason from the model, shown on the job object, is removed about 24 hours after the job finishes.
• Idempotent retries. If you send an Idempotency-Key header on an image or video request, we keep that one response for about 24 hours so a retry gets the same result instead of a second charge. Without the header, nothing is kept.

What we record for an inference request

Every inference call writes exactly one metering record. That record holds:

• who: the organization and the API key id that authenticated the call (and, for dashboard playground calls, the user);
• what: the model id, the modality (chat / embeddings / image / video), and the provider that ultimately served it;
• how much: prompt tokens, completion tokens, cached and reasoning tokens, image count, video seconds, and the computed cost;
• how it went: total duration, upstream latency, time to first token, whether it cold-started, its status, finish reason, whether tools were called, and an error code if it failed;
• when: a timestamp, an opaque request id for support correlation, and the request id you sent, if any: X-Client-Request-Id, or X-Request-Id when that is absent (or metadata.client_request_id on /v1/responses). It is stored as opaque text, so don't put anything sensitive in it;
• billing and status flags: whether your plan covered the call, which surface it came from (API, CLI, dashboard), the HTTP status and public error code, whether the error was caused by the request, quota units drawn, and the names (never the values) of any parameters the model ignored.

Counts, codes, flags and timings, never content. You can read your own usage back at any time with deeprelay usage or GET /v1/usage.

Your request log

The same records back your request log (GET /v1/requests, deeprelay requests, Cloud → Requests in the dashboard). For each request it shows the request ids, timestamps, the model and surface, the API key's id, name and prefix, token counts, the cost, the status and error code, and timing. It never shows the provider that served the call or any upstream timing, and there is no prompt or completion field to show: content is never part of it, for any modality.

Our HTTP access log records the method, path, status code, duration, the connecting network address and organization id of a request, and is kept for 30 days. It never records request or response bodies or Authorization headers. When a model returns an error, our logs keep only its error type and code and a shortened message with any quoted input removed.

Training

We do not train models on your prompts, your completions, or your uploaded files, and we do not hand your data to anyone else to train on. Our zero-data-retention agreements bar our upstream providers from training on it too (except web search, see the web search exception). deeprelay is an aggregator — we route your request to a model someone else trained and bill you for the tokens.

Fine-tuning is the one place your data becomes a model artifact, and only because you asked: a fine-tuning job trains on the dataset you upload and produces an adapter that belongs to you. That dataset is not used to train anything else. Fine-tuning is outside zero data retention by nature: the dataset is stored so the job can train on it.

Model routing and jurisdiction

deeprelay's catalog is served by upstream partners, and those partners are not all in the same country. Some models are served from partner infrastructure located in other jurisdictions, including China; requests to those models transit those jurisdictions. Your prompt and the generated completion leave our US infrastructure and are processed on the partner's hardware under that partner's terms and that country's law.

Everything else is served from US infrastructure (us-west-2).

This matters for you if you have data-residency obligations. Two things follow:

• The jurisdiction is a property of the model, not of your account — you control it by controlling which model ids you call.
• Partners meter on their side, and a partner that offers discounted cache-hit pricing (see Prompt caching in the inference guide) holds your prompt prefix for a short window while serving your requests. That is transient processing to serve you, within our zero-data-retention agreements; it is not storage of your request.

If you need a hard guarantee that no request leaves a given jurisdiction, pin your workload to models whose datacenter you have verified, or talk to us.

Retention

The metering record described above is the billing record. We keep it for as long as we need to bill you, show you your usage history, and satisfy the accounting and tax retention rules we are subject to, which in practice means for the life of the account. It contains no prompt or output content. It is visible in your request log for 90 days; after that it drops out of the request log and its export, but the underlying record is kept for billing.

Everything else follows the windows above: access logs 30 days; video files served for 24 hours and deleted within about 3 days; video prompts until about 15 minutes after the job finishes; a video job's failure reason about 24 hours after it finishes; idempotent responses about 24 hours. Availability snapshots and GPU market price history are pruned on a rolling 365-day window. The provider metadata we publish to aggregators reports zero data retention (except web search, see the web search exception).

Deletion and export

• Your usage history — readable any time via deeprelay usage / GET /v1/usage.
• Your request log — the last 90 days, per request, via deeprelay requests / GET /v1/requests or the dashboard at /cloud/requests; export it as CSV with deeprelay requests export / GET /v1/requests/export.
• API keys — revoke immediately from the dashboard at /cloud/api-keys. Revocation takes effect on the next request; we store only a SHA-256 hash of the key, never the key itself.
• Account deletion — email support@deeprelay.ai. We deactivate keys and stop all routing immediately; billing records are retained as described above.

Questions

Security or privacy questions, including vendor questionnaires and data-processing agreements: support@deeprelay.ai.