How we operate
What we send upstream and to whom, which providers we allow and why, what we keep, and how to check any of it on a request you made. This page is written to be checked against the code, not to reassure.
Data policy, at a glance
The short version a firm can put in a diligence file. Every line links to the detail below.
- Your prompts and answers, by default. Content is logged only if you turn
log_contenton for a key. - Anything used to train a model. Every request routes with
data_collection: "deny". - Your case-law queries as training data. The shared library is read-only; your queries are not added to it.
- Your data with any provider, when you set zero data retention on the key.
- Billing metadata per request: key, model, token counts, cost, latency, a request id. Never the content unless you opted in.
- Files you upload to a matter, isolated by your account id and returned only into your own requests. Delete a matter to delete them.
- First-party page views on the website (not the API): path, a one-way IP hash, coarse device, no cookies.
- The verification report per request (which citations existed, which were removed), so you can audit an answer.
Private inference: routed to a model on hardware you control, no prompt or answer leaves your environment at all. The public library never trains on customer data, and citation verification runs against our own index, so a citation check never sends your text to a third party.
What we send upstream, and to whom
A chat request to DocketRouter is one model call. We build the prompt (your messages, the retrieved rules and opinions, and excerpts of your own case files when you ask for them) and send it to one model provider through OpenRouter, using a sub-key that belongs to your account. Nothing else sees the prompt: citation checking runs against our own library, not a third-party service, and grading, reranking and rewriting run in-house or on the same call.
Three things go with every upstream call: the prompt, the model id, and a provider object that tells OpenRouter which providers it may use for this request. That object is built from your key's policy and cannot be widened by a request.
If the request is private pod, none of this applies: the model runs on our own hardware and the prompt never leaves it.
The provider allowlist
Every request carries only set to the providers below, or to the subset you chose on the key. OpenRouter routes to nothing outside that list. The list is providers whose published data policy says they do not train on prompts, and which are either the model maker itself or a host that publishes zero-data-retention endpoints. Providers whose policy says they may train (at the time of writing, OpenRouter lists DeepSeek first-party, Nvidia, Liquid and Thinking Machines) and decentralised networks are not on it. DeepSeek models are therefore served by hosts such as DeepInfra, never by DeepSeek itself.
Base slugs cover their variants: deepinfra permits deepinfra/fp8. You can narrow this list per key (allow list, preferred order, fallbacks on or off) on the keys page or with PATCH /api/v1/keys/{id}, and narrow it again per request with docketrouter.provider. Naming a provider outside the list is a 400.
Why a list at all: OpenRouter's default is price-weighted load balancing across every host of a model. For a legal prompt, "whoever is cheapest this minute" is not an acceptable answer to "who saw my client's facts". The list makes the answer finite, and the response tells you which one it was.
Default deny on training and retention
Every key routes with data_collection: "deny". In OpenRouter's words, that means: "use only providers which do not collect user data", as opposed to the default allow, which permits "providers which store user data non-transiently and may train on it". There is no request-level way to turn this off; a request may set it to deny (a no-op) and nothing else.
OpenRouter's note on the source of these policies: "This is not a definitive source of third party data policies, but represents our best knowledge." And on the unknown case: "If OpenRouter is not able to establish or ascertain a clear policy for a provider or endpoint, we take a conservative stance and assume that the endpoint both retains and trains on data and mark it as such." We rely on that classification; we do not audit providers ourselves.
Zero data retention on request
Set a key's data policy to no_retention (or send docketrouter.provider.zdr: true on one request) and the upstream call carries zdr: true. OpenRouter: "When zdr is set to true, the request will only be routed to endpoints that have a Zero Data Retention policy." ZDR endpoints are enumerated at GET https://openrouter.ai/api/v1/endpoints/zdr, which "is automatically updated when there are changes to a provider's data policy".
What it guarantees, per OpenRouter: "Zero Data Retention (ZDR) means that a provider will not store your data for any period of time." If no ZDR endpoint can serve the model, the request fails (OpenRouter returns 503, "There is no available model provider that meets your routing requirements") and we return that to you as a 503 with the policy attached. We do not fall back to a retaining endpoint.
What it does not guarantee, also per OpenRouter: in-memory prompt caching is allowed under ZDR ("OpenRouter has taken the stance that in-memory caching of prompts is not considered 'retaining' data"); ZDR "only applies to provider routing for inference requests" and not to plugins or tools; a provider's endpoint-level policy can differ from its general one; and the classification is OpenRouter's best knowledge, not a contract between you and the provider. OpenRouter itself states: "your prompts are not retained unless you specifically opt in to prompt logging." We do not opt in.
Each request is priced from the actual upstream charge for that call plus the DocketRouter margin. When the citation check sends your model back to fix its own answer, that extra call is billed only if the cause was a citation your model fabricated; if the cause was a citation our library could not confirm, we absorb it. The split is reported per request in the usage log.
What we log
request_id, the upstream generation id, and the provider that served it. No prompt, no answer.log_content is on. Off by default. When on, the last six messages and the answer are stored on the usage row so you can review them in Activity; turn it off and nothing further is stored.GET /api/v1/usage and GET /api/v1/usage/{request_id} with your key return exactly these rows.Case files
Files you upload are stored per client, isolated by owner id in every query, and retrieved only into your own requests. Encryption at rest (AES-256-GCM per owner, with a blind index so search still works) is built and switched on per host. On this host it is not enabled. Retention: a file's own retention period wins, then the host default, else the file is kept until you delete it.
A case file is untrusted input. Instructions found inside one are flagged (or the request is blocked, if you ask) and never followed. See case files and injection.
Private pod
A private-pod key may only call in-house local/ models. The prompt, the retrieval and the answer stay on that machine; no provider object is built because there is no upstream. Citation verification against external services is off on a pod unless the firm turns it on. Private pod is set by us when a key is attached to a pod; it is not a self-serve setting. On this host a pod endpoint is configured.
Citation verification is library-only
Every citation in an answer is checked against our own copy of the reporters and rules. No live lookup to a third-party service happens in the customer path, so the act of verifying an answer does not disclose the citations, or the question behind them, to anyone. Statuses and what to do with them: citation verification.
How to see what served your request
Every response carries three headers: x-docketrouter-request-id (our id, the handle for support and for the usage row), x-docketrouter-generation-id (OpenRouter's id for the upstream call) and x-docketrouter-provider (the provider that served it, as OpenRouter reported it). The JSON body repeats them in docketrouter, alongside the policy that was in force:
"docketrouter": {
"data_policy": "no_retention",
"zdr_requested": true,
"provider_prefs": { "data_collection": "deny", "zdr": true, "only": ["deepinfra", "together"], "order": ["deepinfra/fp8"], "allow_fallbacks": false },
"provider_served": "DeepInfra",
"generation_id": "gen-…",
"request_id": "req_…"
}provider_prefs is the exact object that went upstream. provider_served is what came back. If they disagree with what you expected, quote the request_id to hello@docketrouter.ai.
Quotations are from OpenRouter's documentation at openrouter.ai/docs (provider routing, zero data retention, provider logging, data collection) as read on 2026-08-27. The enforcement described here lives in the request path itself, not in a policy document. Developer detail: providers and data.