Docs

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.

Lifecycle

01You call POST /v1/snapshots. We tar-gzip the current namespace contents and store the archive. You get back a snapshot_id.
02The snapshot starts a 30-day clock. It stays untouched until either you delete it or that clock runs out — whichever happens first.
03POST /v1/snapshots/{id}/restore rewinds the namespace to that exact state. The snapshot itself stays available until it expires or you delete it — restore does not consume it.
04DELETE /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.

Yes — delete a snapshot and it's gone forever.

We do not retain a copy of deleted snapshots. The 30-day retention applies to undeleted snapshots — once you call DELETE, that clock no longer matters. If you need to keep an archive longer than 30 days, take a fresh snapshot before the old one expires, or download the tarball via 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

Filesystem deletes are immediate.

We do not maintain a trash bin or grace period for files or namespaces. If your agent runs the wrong command, your only recovery path is a snapshot taken before the delete. Take checkpoints liberally.

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.

Snapshots — for files and namespaces

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.

API reference Open Files

Project undo — for accidental dashboard deletes

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.

Webhooks — for events older than 7 days

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 reference

Compliance 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.

Soft-deleting a project does not delete its data.

Removing a project from the dashboard only forgets it on the dashboard. The workspace, every namespace, every key, every webhook stays alive on the backend. For a true deletion, walk the workspace and delete each namespace and key explicitly.

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.