Data retention
How long we keep each category of data, what happens at expiry, and what we cannot promise.
Retention periods are a public commitment, not an internal tuning knob: the figures below match what actually gets deleted, and changing them is treated as a compliance change.
How long we keep things
| Data | Retained | At expiry |
|---|---|---|
| Generated artefacts (image / video / audio) | About 14 days | Deleted from object storage |
| Reference images you upload | 7 days | Deleted from object storage |
Task content (prompts and parameters in input, artefact references in output) | 30 days | Both fields are cleared; the task row itself is kept |
| Task records (task ID, model, state, amount, timestamps — no content of any kind) | Kept indefinitely | Not deleted. It is the evidence behind a billing dispute |
| Task logs and events (state transitions, webhook delivery records) | At least 60 days (monthly partitions, so 2–3 months in practice) | Deleted |
| Balance and ledger records | Outside the task-content cleanup window | Kept for account history, reconciliation and disputes — see below |
| Database backups | 35 days | Rolled over |
These numbers are server configuration, not hard-coded constants
The table lists the defaults currently in force. Operations can change them — jurisdictional requirements move — but any change is handled as a compliance change: this page and the actual deletion behaviour have to stay in step.
If you need a different retention period written into a contract, raise it before signing rather than assuming from this page.
Why “about 14 days” and not “14 days exactly”
Artefact deletion is executed by an object-storage lifecycle rule, and the official behaviour is that objects are removed within 24 hours of expiry. Promising a whole number while actually deleting at 14 days plus up to one more would be a false statement on its face, so we say "about".
Download anything you need to keep. Once the window closes, no download link can be issued — though the task record remains queryable and balance movements remain visible in billing history.
Expiry clears fields, not rows
Both halves of this sentence matter — the first one alone is misleading
Content is erased after 30 days; the billing and status record, which contains no content, is kept indefinitely.
Stating only the first half is literally true and still leaves the wrong impression, because what disappears is the contents of input and output, not the task record.
What expires is the input and output fields. The task row itself is kept indefinitely — it is the only evidence behind a billing dispute, and deleting it would break the books. After expiry each row is a few hundred bytes of metadata: task ID, model, state, amount, timestamps, originating key.
So after 30 days:
- You can still answer "how much was I charged this month, which tasks failed, which key submitted them".
- You cannot answer "what prompt did I send, which object key held the artefact" —
recordInfostops returninginputandoutputfrom that point on.
If you need prompts for longer, keep your own copy. This period is not extendable per account.
Balance history is separate from task content
Clearing a task's input and output after 30 days does not alter top-ups, holds, settlements, refunds or manual adjustments. You can still reconcile those balance movements on the console's billing page. We do not publish one fixed retention term for every ledger record.
If an access or deletion request reaches data that must be kept for a dispute, a security investigation or applicable law, our response will explain the scope and reason.
Two things we cannot do
1. The upstream model provider necessarily sees your prompt in the clear
Generation happens at the upstream model, and the prompt has to reach it as plaintext. That is an architectural ceiling, not a setting. Our retention periods can therefore only ever promise how long SpicyAPI itself keeps something.
Upstream providers have their own retention and training policies, which we label on each model's page. If that matters to you, read that column before choosing a model.
2. “Deleted immediately” does not exist
Object-storage lifecycle rules have an execution window of up to 24 hours, and database backups roll over 35 days. Any claim that data vanishes from the world instantly is untrue. What we can commit to is how long completion takes, not that it is instantaneous.
The exception: legal holds
Tasks touched by a dispute, a forensic request or a statutory reporting obligation are placed on hold and stop counting down until the hold is released.
This overrides every figure above. It is not a quietly reserved backdoor: without a hold mechanism, the first legal letter would force any retention promise to be broken — and you would then have to explain why the documentation said 14 days. It is written here because it belongs here.
What is in your hands
- Do not send what you do not need to send. Reference images and prompts are the two most sensitive items, and the only two whose content you choose.
- Archive your own artefacts. They last about 14 days here.
- Do not store download URLs in your database. They expire in 20 minutes and cannot be revoked once issued. Sign one when you need it — see Media.
- Use HTTPS for callback URLs. The payload carries task state and artefact references; plain HTTP hands them to anyone on the path.
We do not train on your content
Your prompts, reference images and artefacts do not enter any training set.
The boundary of that sentence matters: it is about us. Upstream providers set their own policies — see the first point above.