# Data storage

> The Markdown form of https://openfill.ai/docs/storage. The index of every docs page is https://openfill.ai/llms.txt, and every page in one file is https://openfill.ai/llms-full.txt.

Storage is off by default. With it off, interactive prompts and responses are removed after completion; batch files have a minimum collection period. This page is what is kept in every state, for how long, and every control you have over it.

## What is kept

| Data | Storage off | Storage on | Control |
| --- | --- | --- | --- |
| Prompt and response of a request | The request body is written to the database at submission, so a detached or batch order survives a restart, and deleted when the order reaches a final state. The response is streamed back and no copy of it is stored. | Kept for your storage period, up to 30 days, as the stored result and, when logging is on, the request log. | Settings, per account. retention_days keeps less on every wire; store: false also does so on chat, completions and Messages. |
| The result of a detached request | Never stored; the result URL answers 410 after successful completion. Failed, canceled and expired orders return their terminal state with 200. | Kept for the storage period. Read as often as you like until it expires. | As above, plus DELETE /v1/orders/{id}/result. |
| The result a replay returns | A replay after completion answers 410. | The stored result, for the storage period. | As above. |
| Batch input file | Kept at least 1 day after upload. | Kept for the storage period after upload. | Settings. The expiry stamped at upload is a ceiling: raising the setting never extends an existing file, and lowering it brings the expiry forward. |
| Batch output and error files | Kept at least 1 day after the batch completes, then deleted. | Kept for the storage period after the batch completes. | Settings. x_retention.output_expires_at on the batch is the instant. |
| The order row and usage record | Kept: id, model, token counts, the price applied, the charge, timestamps and status. This is the billing record. | The same. | None. Kept after account deletion as the billing record; the Data Policy gives the period. |
| Records of each request without its content | Kept: the request's shape (counts, size, the options it set, the client library), each attempt to execute it, refusals counted per minute, and each key's daily activity with network prefixes and countries. | The same. | None. Each has a fixed period, and account deletion removes or unlinks it; the Data Policy lists them in section 5. |

Nothing sent to the API is used to train anything. The [Data Policy](https://openfill.ai/data-policy) is the document behind this page; where the two differ, the policy governs.

## The account setting

On [Settings](https://openfill.ai/settings) you choose what to keep (nothing, results, or results and request logs) and for how many days, up to 30 days. The setting is read at the moment a request finishes, so turning storage off while a request is queued means its result is never stored, and lowering the period shortens data already stored.

Stored data is capped at 100 GB per account. Past it, the oldest stored bodies are deleted to make room; nothing is refused.

| Field on GET /v1/rate-limits | Meaning |
| --- | --- |
| retention_days_max | The longest storage period you can set. |
| stored_bytes_per_account | The cap on stored bodies. |
| batch.min_retention_days | The floor under batch files. |
| payload_logging_available | Whether request logs can be kept at all on this deployment. |

## Per-request controls

Chat, completions and Messages accept both fields. Responses accepts retention_days; its store field is only echoed. The same wire rules apply to batch lines, whose results and files still have the batch collection floor.

| Field | Effect |
| --- | --- |
| store: false | Nothing durable for this request: no result, no request log. The order row and its charge remain. On a batch line the result is still written for the batch floor, so the output file can assemble. |
| retention_days: N | Keep this request's data for N days, clamped down to the account setting. 0 is the same as store: false. |

```json
{"messages": [{"role": "user", "content": "hi"}], "price_limit": 0.10, "store": false}
```

A detached `202` reports what it did: `result_stored` and `result_retention_days`, plus a `warning` when nothing is kept. `GET /v1/orders?include=storage` reports `result_stored` and `log_stored` per order afterwards.

## Deleting early

### One result

`DELETE /v1/orders/{id}/result` removes the stored result ahead of the period. A request log kept for the same order is untouched; it goes at the end of the period or with the purge. The delete is refused while the result is still being written, and while the order is a line of a batch that is still running.

### Everything

Settings has a purge that removes every stored result, request log and batch file on the account. It is queued and runs in the gateway's hourly housekeeping pass, so it can take up to an hour to start and continues across passes until everything is gone. Deleting the account, also in Settings, removes what it holds; the [Data Policy](https://openfill.ai/data-policy) says what survives and for how long.

> Batch files ride a floor the setting cannot lower: input, output and error files are kept for at least 1 day unless deleted early or evicted under the storage cap. A line's temporary result is kept for assembly; after assembly it follows the account setting. File deletion and the purge can remove files early. When the output file is on that floor, the completion email says when it goes.

Previous: [Errors and retries](https://openfill.ai/docs/errors). Next: [API reference](https://openfill.ai/docs/api).