Trash & recovery

Two safety nets — a trash for deleted records you can restore one at a time, and hourly snapshots that let a workspace owner roll catalog, channel, or settings data back to a point in time.

Foundry has two distinct safety nets, and they answer different questions.

• Trash answers “I deleted something I shouldn’t have.” Deleting a record hides it rather than destroying it; you restore it from the trash.
• Recovery answers “an import, bulk edit, or price change went wrong and touched thousands of rows.” Foundry keeps hourly snapshots of your data and lets a workspace owner roll a whole area back to an earlier point — or restore just the rows they choose.

Trash

Deleting a product, brand, category, warehouse, sales channel, assembly (BOM), template, mapping rule, pricing rule, order, purchase order, or invoice moves it to the trash. It disappears from lists, searches, storefronts, and exports, but nothing is destroyed. Restore it and it comes back with its history intact.

Where to find it

• Settings → Trash lists every trashed area in your workspace with counts — channels, brands, categories, warehouses, assemblies, templates, mapping rules, pricing rules. Click through to see the items and restore them one at a time or all at once.
• Products → Trash (in the Products page menu, with a count badge) has its own page: restore per row, Restore all, or Restore by date — everything deleted on or after a day you pick. That last one is the tool for “someone bulk-deleted a batch yesterday.”
• Orders, purchase orders, and invoices are restored through the API (POST /orders/:id/restore and friends) — there’s no admin page for them yet.

What restoring a product does

A product goes to the trash together with its variants and its bills of materials. Restoring brings back the product, the variants that were deleted with it, and their BOMs. A variant you had trashed separately beforehand stays in the trash — restoring the parent doesn’t quietly revive a decision you made earlier. Restore that variant on its own with POST /variants/:id/restore.

If a product is a component in someone else’s active assembly, it can’t be deleted at all — Foundry refuses rather than leave a BOM pointing at a missing part.

How long things stay

Products, variants, orders, purchase orders, and invoices are permanently removed 90 days after deletion, by a nightly job. Everything else in the trash is kept indefinitely — a deleted brand or warehouse can be restored months later.

What is not soft-deleted

Two things are removed immediately with no trash entry:

• Channel SKUs. Deleting listings from a sales channel is permanent — the admin says so before you confirm. Foundry takes a snapshot right before a bulk delete, so the way back is Recovery, not the trash.
• Stock. Inventory is never “deleted”; it moves. If a count or adjustment went wrong, re-apply a correcting count — the movement history shows exactly what changed. See Warehouse operations.

Trashing a whole workspace

Closing a workspace puts the organization itself in the trash. Every request to it is refused while it’s there, and anyone signing in sees a “Workspace in trash” screen; an Owner can restore it from that screen. Foundry staff can permanently delete a trashed workspace on request — that’s the only way a workspace is ever hard-deleted.

Recovery

Recovery is point-in-time restore for your data, built into the admin. It exists because the worst data loss in an inventory system isn’t a deleted record — it’s a bad CSV mapping that overwrote 20,000 prices, or a bulk edit applied to the wrong selection.

What’s captured

Every hour, Foundry snapshots three areas of every workspace:

Snapshots are complete copies of those tables, including records currently in the trash, stored encrypted in Foundry’s own storage — not in your database.

Not covered: stock levels and movements, bins, orders and reservations, fulfillments, purchase orders and invoices, work orders, users and roles, API keys, the image files themselves (only their records), and the activity log. Those live in a transactional history of their own; for inventory the correction is a count, and for orders the source channel is the system of record.

When snapshots are taken

• Hourly, on the hour, kept for 24 hours.
• The midnight (UTC) snapshot is kept as a daily for 30 days.
• Before risky actions, automatically, kept for 30 days: before a CSV import runs, before a price change is applied, before a channel-SKU bulk edit or bulk delete, before a mapping rule is applied to existing rows, and before any previous restore. These show in the Recovery timeline as “Before CSV import”, “Before price change”, and so on — so the snapshot you want is usually the one labeled with the action that went wrong.

A pre-action snapshot that fails never blocks the action itself; the hourly one is the backstop.

Who can restore

Only a workspace Owner. Admins and members see the Recovery page but can’t run a restore, and no API key scope can grant it. Ask your owner to run it, or have them make you an owner.

Running a restore

Settings → Recovery, then:

1. Pick what to restore — Catalog, Channels, or Settings. A restore is scoped to one area; restoring Channels doesn’t touch products.
2. Pick a snapshot — grouped as “Before recent actions”, “Last 24 hours”, and “Last 30 days”.
3. Preview. Foundry diffs the snapshot against what’s live now and shows, per table, how many rows it would create, update, or delete, with samples. Three checkboxes control what the restore does:
   • Restore created rows (on by default) — bring back rows that existed then and are gone now.
   • Restore modified rows — overwrite rows that changed since the snapshot with their old values.
   • Delete rows added since snapshot — remove rows that didn’t exist at the time. This one is destructive; the confirm dialog says so. For any table, Select rows… narrows the restore to specific records — search, tick the ones you want, and only those are touched. Download the full diff exports every proposed change as CSV so you can review it outside the browser first.
4. Apply. Foundry takes a fresh “Before previous restore” snapshot first — and refuses to continue if that fails — then applies the change in a single transaction. The result screen links to that snapshot as your undo.

Restores are recorded in the audit log.

Things to know before you rely on it

• Snapshots include trash state. “Restore modified rows” puts each row back exactly as it was, including whether it was in the trash at the time. Restoring to before a bulk delete un-deletes; restoring to after a deliberate cleanup can re-delete.
• Rows are restored verbatim. A restore doesn’t re-run business logic — it doesn’t recalculate prices, push to channels, or re-sync listings. After restoring Channels, push the affected channel if the external store also needs correcting.
• Scope is one area at a time. A catalog restore that brings back a product doesn’t bring back its channel listings; run a Channels restore to the same snapshot if you need both.
• Very large workspaces (millions of rows) should contact support rather than restore through the admin; the transaction is sized for typical catalogs.

Trash or Recovery?

Related

• Warehouse operations — correcting stock through counts and adjustments
• Importing data — the most common reason to need Recovery
• Authentication & API keys — roles, including what only an Owner can do