Data Policy

This Data Policy covers Customer Content: the prompts, messages and files you send to the API, and the completions we return. For personal data about you as an account holder (your name, email, billing details and sign-in sessions), see the Privacy Policy. This document forms part of the Terms of Service, so the commitments below are contractual.

For Customer Content we act as a processor: we handle it only to carry out the request you sent, and on your instructions. You remain responsible for what you put into a prompt.

By default we do not store your prompts or completions. A new account is created with data storage set to Nothing. We hold your request only for as long as it takes to execute, stream the response back to you, and write no copy of either to durable storage. What the capacity that executes a request receives, and on what terms, is set out under "On execution" in section 9.

Retention is something you turn on. If you want to be able to fetch a result later, or inspect request and response bodies in the dashboard, you can choose what is kept, and for how long, under Data storage in Settings. Two consequences follow from this default:

• Order history shows metadata only (model, token counts, price, status). It does not show what you asked or what came back, because we no longer have it.
• An idempotent retry works while the original request is still executing. Once it has finished, a retry with the same Idempotency-Key returns 410 result_unavailable, because the response was not kept. Use a new key to execute again.

There are four cases in which content exists even with retention set to Off.

• While your request is queued. Your request body is written to our database when you submit it, because an order can wait in the queue before a machine picks it up, and we need the body to execute it. It is deleted when the order reaches any final state: filled, expired, cancelled or failed. It is never included in a database backup (see Backups).
• The Batch API. Batch results and batch input files are kept for a day regardless of your data storage setting or a per-request store: false, unless you delete them earlier. This is unavoidable: a batch job is asynchronous, so the output has to exist for you to collect it. If you need zero retention, do not use Batch.
• Routing cache keys. See Prefix routing cache below. These are hashes derived from your content, and are treated as pseudonymised rather than anonymous.
• On the capacity that executes it. A provider that executes a request may hold the request and its context in memory for a short time after the response, measured in hours, so that a follow-up request can reuse what was already computed. It may also keep a derived numerical representation of a prompt for cache lookups, with no fixed period; it is not designed to reproduce the text, and we treat it as pseudonymised rather than anonymous, as we do our own routing keys. Both are set out under "On execution" in section 9.

Retention is governed by an account setting and two per-request parameters. They combine in one direction only: a request can only shorten retention.

Storing bodies is best effort. Request and response bodies are written from a buffer, and when that buffer is under pressure the oldest entries in it are discarded, so a record inside a retention period can be missing the bodies for some requests. Bodies are shed before stored results are.

Lowering your account retention is retroactive. Eviction is evaluated against your current setting rather than the value that applied when the data was written, so reducing retention (including to Off) shortens data that is already stored. Deletion is carried out by a scheduled process and completes within hours.

Note that our store parameter differs from OpenAI's parameter of the same name. OpenAI's defaults to false and controls whether OpenAI retains a completion for its own product features. Ours defaults to your account retention setting and controls only whether a copy is retained for you to retrieve.

Some records exist regardless of your retention setting, because we cannot bill you, run a market, or find and fix faults without them. None of them contain prompt or completion text.

We do not train, fine-tune, or evaluate any model on your prompts or completions. This commitment is unconditional. We operate no training pipeline, and there is no setting, plan or endpoint that would enable one.

The training commitment covers our providers as well as us. Requests execute on capacity we operate and on capacity we obtain from providers, and we permit a provider to reach your content only under written terms that grant it no right to train, fine-tune or improve a model on it. What a provider may do with the content beyond executing the request is set out in section 9.

We do not sell or share your data, including as "sell" and "share" are defined under the CCPA. We do not use it for advertising, and we do not disclose it to third parties except the sub-processors described below, which handle it to deliver the service and may use hosting and similar providers of their own, and except where the law requires.

We serve open-weight models.

We run no automated scanning of your content: no moderation classifier, no abuse-detection model, and no retention window maintained for trust-and-safety purposes.

We reserve the right to inspect specific content where we are legally compelled to, or where we are investigating a specific report of abuse, and to preserve it for as long as a legal obligation requires. Where content indicates child sexual abuse material, we will report it to the relevant authorities and preserve it as the law requires; this obligation overrides the retention controls described above.

The network that carries requests to us screens that traffic for attacks on our service, as such networks do, with automated rules that match the connection and the request, its content included, against patterns of known exploits. A request that matches one is refused at the network before it reaches us. Those rules exist to protect the service, and neither they nor we classify or moderate what your requests ask for.

This section describes our own systems. A provider that executes a request may watch how its service is used, by request rates and similar figures, to detect abuse of that service; what it may do with the content is governed by section 9.

To send a request to a machine that already has its context cached, we keep an in-memory map of which machine holds which prompt prefix. Each entry stores a truncated SHA-1 digest (20 hexadecimal characters) of your prompt, or of a leading slice of it, together with the prompt's character length, scoped to your account and the model.

The map holds no prompt text, is never written to disk, is not included in backups, and each entry is discarded within 25 hours at the latest: an entry expires a day after it is first seen, and the sweep that removes it runs hourly. We describe these as pseudonymised. They are not anonymous: a truncated hash beside an exact length is not reversible in general, but a short or predictable prompt could in principle be confirmed by guessing. Entries in this map are scoped per account, so it never routes one customer's request using another customer's history.

The capacity that runs your request may keep a cache of its own, shared by everything running on it. It is what makes a repeated prefix cheap: the number of tokens already held is reported back to you in usage.prompt_tokens_details.cached_tokens and is why a cached token is billed at a fraction of a fresh one. Because that count reflects the cache rather than your account, someone who could guess a prompt prefix exactly, token for token, could confirm from their own bill that something starting that way had been processed there recently. It identifies no account, and it is not anonymous: it can confirm a prompt that was already guessed, and a derived cache entry may encode how similar two prompts are. If your prompts are sensitive enough that this matters, ask us about dedicated capacity before you send them.

The named third parties below hold account data or stored content. The "Sees content" column marks which of them can reach prompt and completion data.

We have a data processing agreement in place with each of these providers, incorporating the EU Standard Contractual Clauses and the UK Addendum where the provider is outside the UK and EEA. Each agreement is linked above.

On execution. A request executes on capacity we operate ourselves or on capacity a provider operates for us. We use either or both, in any proportion, and change the mix as supply and demand require. A provider that executes a request receives the content of that request in order to execute it and returns the completion to us. Under the written terms that bind it to us, a provider does not train, fine-tune or improve any model on that content, keeps the content itself no longer than execution and the operational caching described in section 3 require, may keep the derived representation described there for longer, uses the content for nothing beyond executing requests and operating the service that executes them, may use hosting and similar providers of its own, and discloses it only where the law requires, to protect its own rights and safety, or to a successor to its business. A provider keeps records of the requests it served, such as timestamps, token counts and latency, that carry no prompt or completion text; those records identify our account with the provider rather than you, because we send a provider no identifier of ours or of yours beyond what your own request may contain. Where a provider makes those records available to us, we copy them into our execution records and match each to the attempt it describes (section 5). We do not publish which provider executed a request. Where you need the identity of a withheld provider in order to meet your own obligations as a controller, we will provide it to you under a confidentiality undertaking.

We will give at least 14 days' notice before adding or replacing a sub-processor, by email to account holders and by updating this page. For a provider this table withholds, the notice describes the change by role rather than by name. If you object, you may close your account and request a refund of your unused balance.

Your request reaches us through the network of the provider named first in the table above, which carries it from the point of that network nearest you, in whichever country that is, and carries the response back the same way. It is received, queued and priced by systems we operate. It then executes on capacity we operate ourselves or obtain from a provider, and that capacity may be located in any country in which we or the provider operate. We do not commit to a country of execution, we may change where execution happens subject to section 9 and to our obligations under the Terms, and we do not publish where a given request executed.

Content we store under this policy, whether because you enabled retention or because a batch output has to be collected, sits in object storage on servers in the United Kingdom, run by the United States company named in the sub-processor table above. Other personal data leaves the United Kingdom: billing goes to a US payment processor and account email to a US sender, both named in the same table.

We make no residency claim for any country or region. If your use requires every stage of processing to stay inside a particular country or region, OpenFill is unsuitable for it unless we have agreed that with you in writing. By sending a request you instruct us to execute it on that capacity, wherever it is located. Where personal data goes to a provider named in section 9, we rely on adequacy regulations where they apply and otherwise on the Standard Contractual Clauses with the UK Addendum in that provider's agreement. Content sent to a withheld provider goes encrypted in transit, without any identifier of yours, under the written terms section 9 describes, and stays there only for the time it takes to execute the request and the operational caching section 3 describes.

The queued-request table is excluded from database dumps and kept out of the write-ahead log, so a database backup carries no raw prompt body. Backups contain account, billing and usage records, and the other records in section 5. Before 2026-09-19 the continuous backup could carry the bodies of requests queued at the moment it was taken; those backups are pruned after 28 days.

Stored content is not backed up. Results, request and response bodies, and batch files are held in storage separate from the database, and that storage is not copied, replicated or snapshotted. When a stored body reaches the end of your retention period, when you delete it, or when you close your account, the copy removed is the only copy we hold. A backup would retain that content beyond the period you set, in a location your deletion request could not reach.

A database backup does carry the record that names each stored result and body, and with it the key that opens that body, wrapped under a key the backup does not contain. A body deleted from the record is therefore readable from a backup taken before the deletion only while both that backup and the object holding the body exist: the backup for 28 days, the object until the day the body was due to expire (see Deleting your data), and only with the key we hold.

Content that is not backed up cannot be recovered if it is lost. A stored body is a by-product of a request that has already been answered, so re-running the request produces it again, and an order whose only stored copy is lost is refunded. Account, billing and usage records cannot be reproduced, and the database that holds them is backed up continuously.

Setting retention to Off stops new content being stored and shortens what is already stored. To delete everything already stored at once, without closing the account, use Delete stored data under Danger zone in Settings: it removes every stored result, request and response body, and batch file, and leaves your account, keys, balance and usage history untouched. Revoking an API key immediately stops it being usable. To delete your account and the personal data associated with it, use the same Danger zone. Cancel any queued orders and running batches first, because deletion is refused while they are live. What deletion covers, and the email route, are in Your rights in the Privacy Policy.

Deletion completes within a bounded period. Stored results and request and response bodies are held many to an object, each encrypted under a key of its own that exists only in the database record naming it. Deleting the record destroys that key, within hours, and the bytes it sealed are unreadable from then on, to us as to anyone else. The object that held them is removed by a scheduled process on the day the last body in it was due to expire, since an object holds only bodies due on one day, so a body you delete early leaves storage no later than it would have under the retention period in force, and a longer period set afterwards holds the object only for the bodies still readable in it. A batch file is an object of its own, removed before its record and retried on failure. Every object is recorded before it is written, so a failed write cannot leave an unrecorded copy in storage.

We maintain technical and organisational measures appropriate to the risk:

• Traffic between you and our API is encrypted with TLS, with HTTPS enforced.
• Card numbers never reach our servers. Stripe handles them directly.
• API keys are stored only as SHA-256 hashes. We cannot show you a key again after you create it, because we do not have it.
• Passwords are stored only as scrypt hashes, salted per account. We cannot read them.
• Two-factor authentication (TOTP) is available on your account, with backup codes. Enabling or removing it requires your password.
• Stored prompts, responses and batch files are encrypted with our own key before they leave our servers, in addition to the encryption at rest our storage provider applies. The storage bucket, or a credential to it, does not read them.
• Two-factor secrets and recovery codes are encrypted at rest. Reading the database alone does not recover them.
• Database backups are encrypted before they leave our servers, using a key that is not held on them. A copy of a backup is of no use without a key kept separately and offline.
• Traffic between our systems and the capacity that executes requests is encrypted in transit.
• Database backups exclude queued request bodies by construction. The exclusion is a flag on the dump command, so it holds on every backup without an operator step.

One limitation applies: database volumes are not separately disk-encrypted, so the measures above rather than the filesystem are what protect the data on a running server.

For a vendor questionnaire:

• There is no separate DPA to negotiate or sign. The processor terms required by Article 28 are in our Terms of Service and take effect when you create an account.
• Contracting with us is not itself a restricted transfer if you are in the EU or EEA. The United Kingdom holds an EU adequacy decision, renewed on 19 December 2025 and in force until 27 December 2031. Onward transfers to sub-processors outside the United Kingdom are described in section 10.
• We maintain records of our processing activities under Article 30 and make them available to a supervisory authority on request.
• We complete security and privacy questionnaires on request.

OpenFill is available through OpenRouter. The data attributes we declare there are the commitments made on this page: we do not train on prompts, we do not retain them by default, and we do not publish them. If you reach us through OpenRouter, note that OpenRouter is your counterparty and its own policies also apply to the leg of the request it handles.

If we change this document in a way that materially reduces the protections described, we will give notice by email to account holders before it takes effect. The date at the top is the effective date.