Data retention
Plain-English answers to what happens to my data when I delete it, and what TroveFiles cleans up on its own. Last updated May 2026.
Our philosophy
Agents write a lot of ephemeral data — scratch files, intermediate outputs, log spew — and most of it isn't meant to live forever. TroveFiles leans toward immediate deletes for filesystem data so storage stays predictable, with snapshots as your safety net for anything you do want to keep.
For metadata that's noisy by nature (activity events, webhook deliveries) we apply short TTLs so old records don't accumulate.
The deletes described on this page remove data from the live service immediately. Routine encrypted backups may briefly retain a copy on rolling cycles, as described in our Terms of Service.
How snapshots work
The mental model for the safety net you'll lean on the most.
A snapshot is a point-in-time archive of an entire namespace — every file, every directory, captured as a single compressed tarball. Take one before any operation you might want to undo. Restore wipes the namespace and replays the archive, bringing it back to exactly the state it was in when the snapshot was taken.
- 01You call
POST /v1/snapshots. We tar-gzip the current namespace contents and store the archive. You get back asnapshot_id. - 02The snapshot starts a 30-day clock. It stays untouched until either you delete it or that clock runs out — whichever happens first.
- 03
POST /v1/snapshots/{id}/restorerewinds the namespace to that exact state. The snapshot itself stays available until it expires or you delete it — restore does not consume it. - 04
DELETE /v1/snapshots/{id}is permanent on the same request. There is no soft-delete window, no "deleted but recoverable for 24h" state. It's gone.
GET /v1/snapshots/{id}/download and store it on your own infrastructure.Typical agent workflow: snapshot before a risky exec, run the exec, restore on failure, delete the snapshot on success. The TroveFiles SDKs ship a withSnapshot() helper that wraps this pattern.
When you delete something
What happens behind the scenes for each delete action you can take.
| You delete | What we do | Recovery |
|---|---|---|
| A single file | Removed immediately from the underlying storage. No version history is kept.Restore from a snapshot if you took one before the delete. | Gone |
| A whole namespace | Recursively wipes the namespace tree, immediately. Every file is gone.Restore from a snapshot if you took one before the delete. | Gone |
| A snapshot | Permanently deleted on the same request. There is no soft-delete, no trash bin, and no recovery — even if it was created seconds ago.Other snapshots in the same namespace are unaffected. | Gone |
| A webhook | Endpoint configuration removed immediately. No future events delivered.Past delivery records still age out on their own 7-day TTL. | Gone |
| An API key | Soft-revoked. Marked inactive but the record stays for audit.Cannot be reactivated. Issue a new key instead. | Soft |
| A project (from the dashboard) | Removed from your dashboard only. Backend data is untouched.8-second Undo toast in the UI, plus restore by ID via the projects API. | Recoverable |
Auto-expiration
Some data ages out on its own — no action required from you.
| Resource | Stored in | Auto-deletes after |
|---|---|---|
| Files in a namespace | TroveFiles-managed object storage | NeverStored until you delete them. No automatic expiry. |
| Manual save points | TroveFiles-managed object storage | 30 daysEach manual save point expires 30 days after it was created. Re-snapshot before then to extend, or download the tarball yourself. |
| Daily auto-backups | TroveFiles-managed object storage | 7 most recentTaken automatically once per day for every namespace with data. The last 7 are kept; older ones are pruned the next time the job runs. |
| Activity events | TroveFiles-managed metadata store | 7 daysSubscribe a webhook for any event you need to keep longer. |
| Webhook delivery history | TroveFiles-managed metadata store | 7 daysPer-attempt delivery records — outcome, latency, response body. |
| API keys (active and revoked) | TroveFiles-managed metadata store | NeverRevoked keys persist for audit. Cannot be reactivated. |
How to recover from mistakes
What's available when you need to undo or reconstruct data.
Two flavors of save point work the same way at restore time:
- Daily backups are taken automatically once a day for every namespace with data. The last 7 are kept on a rolling basis — you don't have to do anything.
- Manual save points are checkpoints you take before a risky change. They live for 30 days from creation.
Restore from either kind via the SDK, cURL, or the dashboard's Files tab — click the Save points button on any namespace to see what's available.
The dashboard's "Delete project" flow only removes a project from your view — backend data stays intact. An Undo toast lets you reverse it within 8 seconds, and you can restore later if you still have the workspace ID.
The Activity feed is a 7-day rolling window. If you need a permanent audit trail, subscribe a webhook to your own logging system — every event TroveFiles records is delivered there with a signed payload.
Webhook referenceCompliance and account deletion
What to know if your end-users have a right to be forgotten, or if you're handling a security review.
If a customer asks you to delete their data, the right move is usually:
- Wipe the customer's namespace via
DELETE /v1/workspaces/{ws}/namespaces/{ns}(or the dashboard's per-namespace Delete button). This is immediate and final. - Revoke any API keys you minted for that customer.
- Wait 7 days for the activity events referencing that namespace to age out.
- Optionally, store a record on your end that the deletion happened — TroveFiles doesn't keep a tombstone for namespaces.
Questions about this policy?
If you're going through a security or procurement review and need a clarification, or if your use case needs longer retention than the defaults here, reach out and we'll work with you.