We can't leak
what we never
wrote down.
Zero data retention is not a retention period with a smaller number in front of it. Prompt text and completions are never written anywhere. Not to a disk, not to a log collector, not to a vendor's dashboard.
Two columns. That is the entire database.
Every field we hold appears on the left. If a field is not on the left, it is not on a machine.
We keep — counters only
- 01key id — a random identifier for the credential. Not linked to a name.
- 02request count — how many calls the key has made.
- 03token counts — input and output totals, for billing and capacity.
- 04timestamp — when the call happened.
Four fields. Nothing joined to them.
We never keep
- ×prompt text — never written, never logged, never sampled for review.
- ×completions — the output exists in your client and in memory, then nowhere.
- ×files, images, video frames — decoded in memory, discarded with the request.
- ×IP beyond the connection — no address log, no geo lookup, no fingerprint.
- ×email — unless you put one in an email to us, where it lives in an inbox, not a database.
- ×training data — your requests are not training data. The model is frozen.
Six absences. Each one is a design decision.
The distinction that matters. Most services store your prompt and promise to delete it later. Deletion is a schedule; it is also a window in which a copy can be pulled, subpoenaed, misconfigured, or backed up by accident. Here there is no window, because there is no copy.
What "zero retention" is not
Not "30 days"
No retention window exists to be shortened, extended, or quietly widened in a policy update. The number is zero and the number has no units after it.
Not "encrypted at rest"
Encryption protects a stored copy from someone else. It does not protect you from the holder of the key. We keep nothing to encrypt.
Not moderation by sampling
We cannot review a fraction of traffic for quality or abuse. There is no sample to read.
This page describes the data practice of rawinfer.com
and the inference endpoint behind it. It is short because the practice is short.
There is no data-protection department, no privacy officer, no adequacy assessment, and
no transfer mechanism — because there is no transfer of your content to describe.
01What ZDR means here
A request arrives, is parsed, is forwarded to the model, the tokens stream back, the connection closes. The request body and the generated text exist in process memory for that window and are released afterwards. Nothing in that path writes your content to persistent storage.
Concretely, that means no:
- request log containing bodies — we log counters, not payloads;
- debug capture that could be switched on for a hard-to-reproduce bug;
- quality sampling — no human reads a random slice of traffic;
- error reports that ship the input alongside the stack trace;
- third-party observability sitting on the inference path;
- backups that could contain a copy of something that was never on disk to begin with.
The model itself is frozen. Your traffic does not train it, does not fine-tune it, and does not appear in any evaluation set. There is no feedback loop from you into the weights.
02What a request contains
A completion request is a JSON body and an Authorization
header. The body carries the content; the header carries the key. This table lists every
field the server handles and whether any part of it survives the connection.
| Field | Handled how | Survives? |
|---|---|---|
Authorization header |
Hashed, compared to the key record, discarded | Key id only |
model |
Must be qwen-flash-next; there is nothing else to select |
Constant |
messages / prompt text |
Held in memory, tokenised, released after the response | No |
| Image and video input | Decoded in memory for the request, then released | No |
max_tokens, reasoning_effort, sampling parameters |
Used for this call, not stored per call | No |
| Output tokens | Streamed to your client; counted on the way past | Count only |
| Timestamp and duration | Written to the counter row | Yes, 30 days |
Under TLS, the body is opaque to anything between you and the endpoint. On our side it is parsed once and never serialised again — there is no stage of the pipeline that turns a decoded message back into a string and appends it somewhere.
The practical test. If a bug in our code tried to log a prompt, it would have nothing to log from: the request object is released with the connection, and there is no logger configured on that path. That is a weaker guarantee than "we promise", which is why we describe the mechanism rather than the intention.
03Why we cannot comply with a prompt subpoena
If someone demands "all prompts and outputs for key sk-rwi-…", the response is an empty set. Not a redacted set. Not a set withheld on privilege. An absence, because the record does not exist.
The honest version, in writing, would read: we hold a key identifier, a request count, token totals, and timestamps. We hold no prompt text, no completion text, and no attachments. There is no archive to search and no backup to restore.
This is not a legal shield we built. It is the operational reality that makes the shield irrelevant. We cannot be compelled to produce something that was never created, and we cannot reconstruct it from counters — token counts tell you how many tokens, never which ones.
Two consequences, stated so nobody is disappointed later:
- We cannot prove what a user did. If you need an audit trail of your own requests, build it on your side. We cannot supply one.
- We cannot clear a user either. If someone claims your key generated something, we cannot confirm or deny it. Neither party gets evidence out of us.
04Cookies and tracking
We set no cookies. None for sessions, none for consent, none "strictly necessary" that quietly count something. There is no analytics package, no pixel, no heatmap recorder, no A/B framework, no advertising tag, no fingerprinting script.
The site is static HTML and one small deferred script. It reads no storage, sets no identifier, and sends nothing anywhere. The dashboard and checkout on this site are demonstrations driven by local state; they do not call our API.
The one third-party request. The design system imports a Google Fonts stylesheet. That request discloses your IP to Google's font CDN, the same way loading any page from any host discloses your IP to that host. It sets no cookie we can see and returns nothing to us. It is a stylesheet, not a tracker — but it is the only thing on this site served by someone else, so it belongs in this section.
On API traffic: no cookie, no session, no browser. One header carries the key. Nothing else is required and nothing else is recorded.
05Crypto payment privacy
The chain is public. A payment amount, a timestamp, and two addresses are visible to anyone with a block explorer. That visibility is a property of the network, not of us, and no policy on this page can change it.
What we do not do: we do not require a name, an address, an ID document, a phone number, or a billing address. We do not link a wallet to an identity, we do not build a payment graph, and your wallet is not our record of you. A transaction hash is a pointer to a public ledger entry used to credit a balance — it is not a profile.
If payment privacy matters to you, XMR is accepted for exactly that reason. We do not ask where a payment came from and we do not attempt to find out.
What we cannot offer: a receipt suitable for a tax authority, an invoice with a company name on it, or a confirmation of identity for a bank. There is no company (see Terms §13) and no customer file to sign.
06Email you send us
Support runs on one inbox. An email you send is the one place your words do reach a machine that keeps them — because a mail provider stores mail, and no amount of doctrine changes that. So the rule is simple: send identifiers, not content.
Useful in a support email: a transaction hash, the coin, the amount, the first eight characters of the key, and a plain description of the problem.
Not useful, and never required: your prompt, a completion you disliked, a screenshot of a chat, or an attachment of your codebase.
What happens to mail: it stays in the inbox while a thread is open, it is deleted when the thread is closed, and it is not copied into any database, CRM, or analytics system. There is no marketing list and no newsletter — nothing to unsubscribe from, because nothing is ever sent except a reply to you.
Mail is not encrypted end-to-end unless you arrange it, and a mail provider's retention is theirs, not ours. If a message must not exist, do not send it.
07Retention schedule
Everything we hold, with how long it is held. This table is the complete list.
| Record | Held for | Why |
|---|---|---|
| Key identifier and its hash | Life of the key | Authentication and billing |
| Per-request counter rows (tokens in/out, timestamp) | 30 days, then rolled up | Usage page, rate limiting, capacity |
| Monthly token and request totals | Life of the key | Plan limits and ledger corrections |
| Payment transaction hash | While a balance is creditable | Prevents double crediting; supports ledger fixes |
| Prompt, completion, attachment, or derived text | Never | Does not exist |
Rolling up is not archival: after 30 days the individual rows are replaced by monthly totals, so the per-request timestamp detail stops existing even for us.
08Account deletion
Delete the key in the dashboard. It stops working immediately and the counters are purged. There is no grace period, no soft-delete window, and no restore — so nothing needs to be promised about what happens after 30 days, because nothing is being held while a timer runs.
Deletion is irreversible. There is no copy of your prompts to delete on request, because there was never a copy. What gets removed is four fields and a number.
No refund follows deletion. Credit is a counter, not money — see Terms §6, which applies here without exception.
09Children
The service is for adults: 18 and over, in every jurisdiction, without exception. We do not knowingly issue keys to minors and we do not ask for an age — we ask you to affirm it when you sign up, and we terminate a key found to belong to a minor.
There is nothing extra to delete in that scenario, and that is the whole point: with no prompt archive, no profile, and no contact record, there is no repository of a minor's content for anyone to find.
10Your statutory rights
Nothing in this document removes statutory rights you have under EU or UK consumer law, or under any other mandatory law where you live. That sentence is not a disclaimer; it is the position. Where a right cannot be waived, this page does not waive it.
It also cannot manufacture data. An access request returns your counters, because the counters are the complete set. A portability request returns the same small table. An erasure request deletes a key. There is no deeper file to reach, no shadow copy held for compliance, and no processor to forward the request to — we run the inference ourselves and no third party sees a request body.
We do not run GDPR theatre: no nominated representative, no DPO mailbox, no record of processing in triplicate, no standard contractual clauses for a transfer that does not happen. There is one inbox and one person, and both are described in §10.
11Changes to this notice
The version on this page is the version in force. There is no mailing list to notify, so no change notice can be sent — the version line at the top is the record. We do not quietly widen a retention window, because there is no retention window to widen: a change to that claim would be a change to what this service is, and it would be visible here.
12Contact
Privacy questions, deletion confirmations, and ledger corrections go to ops@rawinfer.com. The support page lists what to include and how fast a reply arrives. Do not paste prompts into an email — we will not read them, cannot store them usefully, and it defeats the point of this page.
Summary. Four fields are kept. Prompt text is never kept. No cookies are set. Payments are public on-chain by nature, not by our choice. Deletion is immediate. A demand for your prompts returns nothing, because nothing is there.
The four questions that arrive most often
Do you store my prompts?
No. Not during the request, not after it, not for a short period before deleting them. The body is parsed, used, and released. Nothing on the inference path writes content to persistent storage.
Can you show me what I sent last Tuesday?
No, and not because of a policy. There is no record of that request to read. Your client or your application's own logs are the only place that history exists — if you need it, keep it yourself.
Do you sell data to anyone?
There is no data to sell. Four counter fields per key, no content, no profile, no contact list. A buyer would receive a key identifier and a number of tokens.
What if someone claims my key produced something illegal?
We cannot confirm or deny it, and we will say so in writing. That cuts against you as readily as it cuts for you — which is worth knowing before you rely on this endpoint for work that needs an audit trail.
Anything not answered here is answered in the terms, or by a reply to ops@rawinfer.com.
Where the rules live
Terms of service
Fifteen sections: the service, the money, the liability cap, and why nothing is ever paid back.
02 / UseAcceptable use
Scope documents, authorised testing, and the one prohibition that has no framing.
03 / DocsAPI reference
Three endpoints, OpenAI-compatible shapes, and what the /v1/usage counters return.