The record trash: seven days to change your mind

Deleting a record in Tabla asks no questions. It can afford not to: the record moves to a per-table trash, stays there for 7 days, and comes back whole. Deleting one row offers Undo on a notice that floats for 8 seconds (and Cmd+Z works after that); deleting several asks once, plainly — "They move to the trash and can be restored for 7 days."

Where it lives

1. Click the chevron on the current table's tab.
2. Choose Deleted records…

Each row shows the record's display value and how long ago it was deleted, newest first, with Load more past the first page. Two actions per row, one for the whole list:

• Restore — the record returns, with its attachments and its links to records that still exist. It reappears wherever the active view's filter and sort put it, and the restore itself is undoable — Cmd+Z sends it back.
• Delete forever… — gone for good, file bytes included, after one confirmation. There is no recovery past this point.
• Empty trash… — the same, for everything at once.

While a record sits in the trash it can't be edited — a write against it is refused with "This record is in the trash. Edit not saved."

The sweep

Once an hour, records deleted more than 7 days ago are purged automatically — the same permanent deletion as Delete forever, on a schedule. Seven days is the whole window; there is no longer tier.

The same sweep, on the same seven days, empties the table trash one level up. One number covers both deliberately: a table restored on day six whose rows had been swept on day five would come back with holes in it.

Who can restore what

Roles apply in the trash the way they apply outside it: an editor deletes, restores, and purges only records they created themselves, and their Empty trash empties only their own. An owner can do all of it to anything. The point is symmetry — an editor who couldn't delete your record can't erase its recovery window either. (What roles can do.)

Webhooks fire once, at delete time

record.deleted fires when the record is trashed, carrying its last known body. Purging — by hand or by the sweep — fires nothing; the event already happened. Restoring fires record.created, because to anything watching the table, a restored record is a new arrival. (Webhook payloads.)

Over the API

The trash is three endpoints on the table:

• GET /api/tables/:id/trash — the trashed records, newest first, each carrying deleted_at.
• POST /api/tables/:id/trash/restore with { "ids": ["rec_…"] }.
• POST /api/tables/:id/trash/purge with { "ids": [...] } or { "all": true }.

The full shapes are in the API reference.

The questions people ask

Does a restored record keep its id? Yes — the trash holds the record itself, not a copy, so it returns as the same rec_…. A record link that pointed at it works again the moment it's back.

Do trashed records count against the record limit? The million-records-per-database ceiling counts live records only. A restore makes records live again, so it counts like creating them — a database sitting exactly at its cap can refuse a restore until there's room.

Can I make the window longer than 7 days? No. Seven days, every table, every plan. For anything longer there's the whole-database export.

What this trash is not

It holds records only, and it is per table. A deleted table has its own trash a level up — same 7 days, same sweep — reached from the ⋮ at the end of the tab strip → Deleted tables…, and restoring the table brings its records back with it, trashed ones included. Deleting a field drops a real column and its data, and deleting a database drops everything in it; neither lands here, and a field deleted while records sit in the trash is gone from those records too. The full map is deleting and what comes back — and nightly backups exist for the genuinely bad day.