Data Flows
This page answers one question: where does data go when you call the Responses API? It covers the outbound side, the systems this service talks to on your behalf, as a counterpart to the inbound API documented in the Responses API reference.
|
The active set is a deployment decision
Which of the destinations below are reached depends on how a deployment is configured, not on the software. Several are off by default and opted into per deployment. Each deployment should record its own configured set, the table tells you which switch governs each one. |
Where data goes
"Customer content" means your prompts, model output, and anything derived from them. "Metadata" means identifiers, sizes and timings. Note that metadata is not automatically free of personal data, filenames and user identifiers survive in it.
| Destination | What crosses | Content or metadata | Governed by |
|---|---|---|---|
Inference layer, via the platform AI gateway |
Your full prompt and the reconstructed conversation history |
Customer content |
Always. Runs outside this service; see below |
LinkUp ( |
Search queries derived from your messages, and the page content fetched back |
Customer content |
|
OpenRouter ( |
The content submitted for content-safety screening |
Customer content |
|
Data Platform (file search) |
Your search query, and the passages retrieved back |
Customer content |
When file search is configured |
Data Platform (image store) |
Uploaded image bytes; this service keeps only a reference |
Customer content |
When image input is configured, see Image Inputs |
Telemetry collector (OTLP) |
Traces, metrics and logs, including tool arguments and results when |
Content and metadata |
Always |
PostgreSQL |
All persisted conversation data, skills and compactions |
Customer content |
Always |
Redis |
Turn payloads in transit between API and worker |
Customer content |
Always |
Third parties
Two destinations are operated by third parties, and content sent to them leaves the cluster:
-
LinkUp for hosted web search, see Web Search, which documents the search depth options and notes that the API key is server-owned, so no per-request user authorization is forwarded.
-
OpenRouter for the
openrouter-llama-guardprovider, see Guardrails. This is a temporary bridge while our own LlamaGuard is unavailable, and it is registered only when its key is set.
Both default to off across the fleet. A deployment that enables either should record the provider in its own processing records.
Inference
Inference does not run inside this service. Requests are forwarded through the platform AI gateway to the inference layer, which runs outside this cluster and is shared across platform consumers. The hop is TLS-encrypted and carries a token.
Which inference backend a deployment reaches, and where it is operated, is a platform configuration decision rather than a property of this service. If you need to state the processing location for a compliance record, take it from the platform’s own documentation for your deployment rather than from this page.
What stays inside
PostgreSQL, Redis and the telemetry collector are part of the deployment’s own infrastructure. They are reached in-cluster over the service mesh, which enforces mutual TLS.
Retention of the data held in PostgreSQL is governed by the policy described in
Managing Responses. If you would rather a turn were not persisted at all,
store: false on the request opts out, also documented there.