Privacy & Data Retention
This notice covers the inference API served at eagleai.online — both the
fixed-price endpoints under /api/v1/ and the per-token provider surface under
/api/openrouter/v1/. It describes exactly what a request leaves behind, because
for an inference proxy that is the only privacy question that matters.
1. What we do with the content of a request
Prompts, messages, tool definitions and generated completions are held in memory only for as long as it takes to forward the request upstream and relay the reply back to you. We do not write prompt or completion content to disk, to a database, or to our logs. We do not use it to train anything — we operate no models of our own and fine-tune nothing.
This is a property of the code, not a promise of intent: the accounting record emitted for every request carries counts, timings and prices and no message content — §2 lists all of it, including the parts that are not counts — and no code path on either surface logs a request or response body.
2. What we do record
One metering record per request, written to a daily file and to the service log. It is a wide record — 33 fields on the fixed-price endpoints, 18 on the per-token surface — because it has to be enough to reconstruct an invoice line and answer a dispute about it without keeping the request that produced it. Not one of those fields is content. What they are:
| Group | What is in it | Why |
|---|---|---|
| identifiers | request id, UTC timestamp, model, a fingerprint of the key (below), whether the reply was streamed; on the per-token surface the name we issued the key under, on the fixed-price endpoints the internal name of the deployment that served it | whose invoice the line belongs on, and joining a support question to a request |
| token counts | input, output, total, cached input, reasoning output; on the fixed-price endpoints also the pre-flight estimate they are reconciled against — estimated input, how it was measured, whether that measurement was exact, and the output budget reserved | the amount billed, and whether the figure came from the upstream or from our own estimate |
| money | what the request cost us upstream and which rate-card version priced it; on the per-token surface what it earned; on the fixed-price endpoints the listed price, the marketplace fee, the net and the margin, plus a named reason whenever any of those could not be computed | invoicing, and knowing which requests we sold below cost |
| timing and outcome | duration in milliseconds, the upstream HTTP status, whether the request succeeded, and whether the token counts were authoritative or inferred | reliability reporting and dispute resolution |
The key fingerprint deserves naming rather than burying. The caller field is not
your key and not a name you chose: it is the first sixteen hex characters of the SHA-256 of the
key presented on the request. It is one-way, so a record cannot be turned back into the secret,
and it is stable, so every request from one key lands on the same value — which is what
makes a per-key rate limit possible and equally makes the field a pseudonymous identifier rather
than an anonymous one. We hold the key it was derived from, so for any key we issued we can
match the two, and you should assume we can.
A request we refuse before contacting the upstream is recorded too, on the fixed-price endpoints: the same identifiers, the status we returned, and our own reason for it — a reason built from counts and limits, never from your text. That line goes to the service log only, not to the metering file, because a refused request has nothing to bill. On the per-token surface a refused request produces no metering record at all, for the same reason.
A second record exists, for one group of customers only. A key issued with a prepaid credit allowance is metered against a small ledger of its own, so that a fixed grant cannot be overspent by requests that are still in flight. It holds one row per request in a local database: the request id, the customer name the key was issued under, the amount reserved for that request, the amount it finally settled at, whether it is reserved, settled or released, and when it opened and closed. Amounts and states only — no tokens, no prompt, no completion. A key with no allowance never opens it, and the per-token surface refuses allowance-carrying keys outright rather than metering them, so it is untouched by anything bought there.
We do not sell, rent or share any of these records, and we do not run advertising or third-party analytics on this API. API keys are compared in constant time; where one has to be mentioned in a log line at all it is masked to its first four characters and its length, and any secret that could appear in an upstream error message is stripped before that message is logged or returned.
3. How long we keep it
Metering records are kept for 365 days and then deleted — the invoicing and dispute window, and nothing past it. The server does the deleting, not a person with a calendar reminder, and 365 days is a ceiling rather than a target: records are filed by the UTC day they were written on, and a whole day is removed once that day falls outside the window, so a record written late in a day is kept for slightly less than the full period and none is ever kept for more.
The sweep runs when a record is written and again whenever our model catalogue is polled, which matters more than it sounds: it means retention does not depend on new inference arriving to trigger it, and a quiet month still ages its records out on time. The same lines are also emitted to the service's system journal, which the host rotates on its own schedule; that copy is a byproduct of running a service rather than an archive we keep, and it carries no content either.
The prepaid-credit rows in §2 are the exception, and we would rather write it down than let the number above cover something it does not. They have no retention window: they are the proof of what a grant was spent on, the only deletion the code contains is an operator clearing the table by hand, and until that happens they stay. If you hold a prepaid key and you want those rows gone, ask (§5).
Prompt and completion content has no retention period here because it is never stored (§1).
4. Who else sees a request
We are a proxy. Your request is forwarded to a dedicated model deployment we operate on a third-party cloud AI platform, and that platform processes it under its own terms. We do not publish which platform on this page — that is a commercial arrangement, not a fact about your data — but we will name it in writing to any customer who asks, and we will name it to anyone who needs it for a data-protection assessment. Withholding a supplier's name from a price list is ordinary; withholding it from someone doing diligence is not, and we are not doing the second. What that arrangement means for your data is below, in full, and none of it changes with the name:
- That platform's abuse-monitoring systems may retain prompts and completions for up to 30 days, in storage it operates and isolates to our resource.
-
Modified abuse monitoring (zero data retention) is not enabled on these
deployments. We therefore publish
"zdr": falsein our provider catalogue rather than claiming a posture we do not hold. If zero retention is a requirement for you, this API is not currently a fit, and we would rather say so here than in an incident review. - That platform is a processor for the inference itself and nothing else. It is not given our metering records, our billing data, or the list of who holds a key.
No subprocessor other than that platform sees request content: there is no analytics vendor, no log-shipping service and no third-party SDK anywhere on this path. Requests reach us over TLS and travel to the upstream over TLS.
5. Your choices
- Ask us what records described in §2 exist for your key, and we will provide them.
- Ask us to delete them, and we will, except where we must keep a record to settle an invoice already issued. This is the route to having prepaid-credit rows removed, since nothing removes them on a schedule.
- Ask us to revoke a key at any time; revocation takes effect on the next service restart.
6. Changes
Material changes to this notice will move the effective date above. We will not apply a weaker retention or disclosure position retroactively to data already collected.
7. Contact
sales@eagleai.online — for privacy requests, data access, deletion, or questions about anything above.