Documentation

Privacy & data

How INFRO handles your data: never trained on, 30-day default content retention, per-request zero-logging, region pinning, and GDPR posture.

INFRO sits between your application and the model providers that serve it, so our data handling is worth reading closely. The commitments are simple: your prompts and completions are never used to train models, never sold or shared, and never sent to anyone except the provider serving your request.

This page covers what is retained and for how long, how to turn off content logging entirely, how to pin traffic to a region, and the compliance details you need for a security review. For how content flows through a request, see Chat completions.

The commitments

Never trained on. Neither INFRO nor any provider we route to uses your prompts or completions to train models — every provider on INFRO operates under a data agreement that prohibits training on API traffic.
Never sold. We do not sell or share request content or metadata with anyone. There is no advertising, analytics resale, or data brokerage.
Minimal transmission. Request content goes to exactly one place: the provider that serves the request. It is not fanned out, mirrored, or sent to any other third party.

If you attach your own provider keys with BYOK, requests to that provider run under your direct agreement with them. INFRO still applies the retention and logging rules on this page to its own infrastructure, and your keys are stored encrypted (AES-256-GCM), never logged, and revocable anytime.

Default retention

INFRO handles two categories of data with different lifetimes. Content is your prompts and completions — the messages you send and the choices that come back. Metadata is what billing and observability need: token counts, model, provider, latency, cost, and status. Metadata never includes message content.

Data category	Default retention	With zero-logging
Prompt and completion content	Up to 30 days, for debugging	Never written to disk
Request metadata (tokens, model, provider, latency, cost)	While your account is active, for billing	Unchanged — requests are still metered
BYOK provider keys	Encrypted at rest until you revoke them; never logged	Unchanged
Account data (email, key labels, spend limits)	While your account is active	Unchanged

Zero-logging changes what is written, not what is billed. A zero-logged request still produces a usage record and still counts against rate and spend limits.

Zero-logging

Two switches control content logging. Per request, set logging: false in the body. Org-wide, flip the zero-logging toggle in the console — it applies to every request from every key in the org, with no code changes.

loggingboolean: Set to false and the prompt and completion content of this request is never written to disk anywhere in INFRO — not in request logs, error traces, or debugging captures. Billing metadata is still recorded. Top-level body field; pass it via extra_body in the OpenAI SDKs.

curl https://api.infro.io/v1/chat/completions \
  -H "Authorization: Bearer $INFRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{"role": "user", "content": "Summarize this contract: ..."}],
    "logging": false
  }'

The console toggle and the per-request field have the same effect. Use the toggle when the whole org should never log content, and the field when only specific workloads carry sensitive data.

With zero-logging enabled we cannot see your prompts, so support investigations of content-level issues — bad outputs, truncation, moderation refusals — rely on metadata alone. Keep your own copies of failing requests if you want help reproducing them.

Region pinning

Set routing.regions to keep traffic inside specific jurisdictions. INFRO then routes only to provider datacenters in the listed regions — the usual building block for data-residency requirements.

routing.regionsstring[]: Any subset of "us", "eu", and "ap". Only providers with capacity in a listed region are eligible to serve the request. If no provider in the pinned regions can serve the model, the request fails with 503 no_available_provider — see Errors.

Request body

{
  "model": "deepseek/deepseek-v3.2",
  "messages": [{"role": "user", "content": "..."}],
  "routing": {"regions": ["eu"]}
}

Open-weight models from Chinese labs (DeepSeek, Qwen, Moonshot, Z.ai, MiniMax) are served from non-China datacenter regions by default — you do not need to pin a region to get that behavior. Pinning narrows the provider pool, so check the model catalog for coverage, and see Routing for how regions combine with provider allow and deny lists.

Providers and subprocessors

Every provider INFRO routes to has signed a data agreement covering API traffic: no training on your content, no retention beyond their stated API terms, no onward sharing. Providers are the only subprocessors that see request content.

The current subprocessor list — model providers plus the infrastructure vendors that handle metadata — is published in the console and updated before any new subprocessor goes live.

For content flowing through the API, INFRO acts as a data processor and your organization is the controller. A standard DPA with SCCs is available for signature in the console. For the strictest posture, pair the DPA with routing.regions: ["eu"] and zero-logging: EU-only serving with no content at rest.

Usage export

The usage export in the console contains metadata only. Each row carries the timestamp, model requested, model and provider that actually served, token counts, cost, latency, finish reason, and key label — never message content. It is safe to hand to finance or load into a BI tool without a data review.