Data retention and privacy controls
Last updated October 12, 2026
How long each kind of data is actually kept, how generated artifacts are stored and cleared, and which controls are available to you.
This page describes what the platform actually does with data, so you can assess it against your own compliance requirements. For the legal statement, see the privacy policy.
Call bodies are not recorded
For successful text and chat calls, request and response bodies are not stored. Prompts and model output are not written to disk once forwarded; the call record holds metadata only: time, model, provider, protocol, token usage, duration, status code, and failure reason. Failed calls are the exception, see "Sampling of failed calls" below.
This means:
- Prompt content is not visible on the logs page — by design, not for lack of permission
- For a successful call, we cannot reconstruct for you what it asked
- We also cannot do anything with that content, including training models
If you need call content retained, record it on your side and correlate it with our records using the x-amux-generation-id response header.
Sampling of failed calls
When a call fails, the cause is often in the request itself (a wrong parameter, an image URL the upstream cannot fetch). To be able to investigate these, failed calls are sampled and kept:
| Item | Handling |
|---|---|
| What is kept | Request body, some request headers (content type, SDK version, retry count, etc.), the error returned by the upstream provider |
| What is not kept | Credentials such as API keys (authentication headers are not recorded; content in the body that looks like a credential is masked); model response bodies; inline images / audio / video (only type and size are recorded) |
| Image URLs | Kept as sent, including query parameters — needed to investigate "upstream cannot fetch the image" |
| Upstream outages | Only the upstream error is kept, not the request body: such failures are unrelated to what you sent |
| Failures not sampled | Authentication failures, insufficient balance, permission denied, and platform rate limiting — unrelated to the request content |
| Sampling rate | Only a few samples per error category per hour; not every failure is kept |
| Who can see them | Only authorized RouterOne staff while investigating issues; every view is recorded in the audit log; not shown on your logs page |
| Retention | No more than 15 days, then deleted automatically |
If you do not want a particular request retained, send it with the header:
x-amux-omit-request: true
If such a request fails, its body is not kept (the upstream error is still kept).
Three kinds of content that are stored
Asynchronous generation tasks
For image, video, and similar asynchronous tasks, the prompt, generation parameters, and material references are stored with the task, outside the rule above.
The reason is that these tasks run asynchronously: results are retrieved minutes to tens of minutes later, and retrieval, retries, and billing disputes all depend on that input.
Retained for 30 days by default, after which the task payload is cleared; the task record itself is kept for reconciliation and audit.
Playground conversations
Messages and model replies in the console playground are stored under your account so that you can pick them up after a refresh or later.
Conversation content is visible only to you and to workspace admins with the relevant permission. You can delete a single turn or an entire conversation at any time, and deletion is not recoverable.
For content you would rather not have retained, call the API directly instead of typing it into the playground.
Tickets and attachments
Ticket content and attachments are stored so that we can handle your request.
⚠️ Do not put anything in a ticket that you would rather we did not see. Attachments are scanned for anything resembling a credential on upload; on detection they are refused and deleted, at which point you should redact, re-upload, and rotate the exposed credential — the file may have been accessed before it was refused.
How generated artifacts are stored
Generated images and video, along with reference material you upload, are stored in publicly readable object storage.
The address contains a random identifier and is unguessable, but anyone with the address can open it without signing in.
⚠️ Do not treat this as private storage. Do not forward artifact addresses to anyone who should not see the content; where access control matters, retrieve the artifact and store it yourself.
Artifacts are cleared on a schedule, after which the address stops working. The artifact section of the log detail page says as much — download anything you need to keep.
This is also a content-responsibility matter: once you have generated something that should not be seen by others, a leaked address cannot be recalled. See the generated content section of the Acceptable Use Policy.
Retention at a glance
| Data | Retention |
|---|---|
| Request / response bodies of text and chat calls | Not recorded for successful calls |
| Sampled failed calls (request body, some headers, upstream error) | No more than 15 days |
| Call metadata (time, model, usage, status) | Long-term, for reconciliation and usage reporting |
| Aggregated usage and transaction ledger | Long-term (statutory financial record requirements) |
| Prompts, parameters, and material references for asynchronous tasks | Cleared after 30 days by default; the task record is kept |
| Generated artifact files | Cleared periodically; no specific period committed |
| Playground conversations | Kept until you delete them |
| Tickets and attachments | Kept after closure; reviewed and cleared periodically |
| Audit records | 2 years |
| On-site search terms | Aggregated into daily counts, with no per-query records |
| Account information | For the life of the account |
Controls available to you
| Need | Action |
|---|---|
| Leave no call content behind | Use the API rather than the playground; bodies of successful calls are not recorded, and for failed calls send the header x-amux-omit-request: true |
| Clear playground history | Delete a single turn or an entire conversation |
| Keep artifacts from staying public | Retrieve them promptly and store them yourself |
| Restrict requests to specific providers | Set pinned providers on the account or key; see routing and failover |
| Avoid value-tier supply | Set the supply-tier scope to "official quality only" |
| Delete the account | Request it through a ticket or by email; see below |
Where data is processed
Our own services and storage are located in the United States.
Upstream model providers decide their own processing locations, and we do not make a blanket statement about them. To confirm where a particular model's data is processed, consult that provider's privacy policy — the model catalog states the provider for every model.
Data flowing to upstream providers
Request content is forwarded to the provider you select or that routing lands on, and is subject to that provider's own privacy policy.
Where data flow matters, set pinned providers on the account or key to confine the candidate pool to the ones you have assessed. That constraint is intersected, and a key cannot widen what the account allows — so setting it once at the account level ensures no key beneath it can exceed it.
Deleting an account
Request account deletion through a ticket or by emailing support@amux.ai. Deletion is handled by anonymization: name, email, and avatar are cleared, source IP addresses are erased from call records, and sampled failed calls are deleted.
The transaction ledger and aggregated usage are retained under statutory financial record requirements; once processed, those records no longer point to an identifiable person.
Related
- Privacy policy — the full legal statement
- Call logs — which fields are recorded
- Providers and supply tiers — restricting where data flows