Archiving & deleting a workspace

Shutting a workspace down and deleting it are the same mechanism with one difference: a date.

	Archive	Delete
Effect	Everyone loses access; the workspace stops doing work	Identical — plus a 30-day timer
Reversible	Yes, indefinitely	Yes, until the timer elapses
Data destroyed	None	After 30 days, permanently
Who can	Owners and admins	Owners only
Confirmation	One click	Type the workspace slug

Nothing is destroyed when you press Delete. The workspace is archived immediately and the deletion happens 30 days later. Until then, Restore brings it back exactly as it was, and Keep it archived stops the clock without un-archiving.

Archiving is deliberately the lighter action, with no typing and a plain confirm. It is reversible, and putting a reversible action behind the same ceremony as an irreversible one only teaches people to click through both.

What happens the moment you archive

Access is revoked immediately — for everyone except owners, who keep the ability to restore. The workspace's attachments are suspended rather than severed: webhook endpoints and notification channels move to disabled, integration connections to suspended (not revoked), repo links to unlinked, and agent routines are turned off. No data is moved, copied, or rewritten.

Your workspace's name and slug are released immediately, so you can reuse them for a new workspace right away. The permanent ws_… Workspace ID is never reused.

What restoring does not bring back

• API keys. They are revoked at archive time and stay revoked — issue new ones. "Un-revoking" a key is a security hole with a friendly name.
• Running agent sessions. Their sandboxes are destroyed so they stop costing you money. The sealed session records remain.
• Your subscription is not affected by archiving and keeps billing. It ends only if the workspace is actually deleted. An archived workspace does not count against your plan's workspace limit.

Everything else — projects, secrets, settings, members, roles, integrations, repo links, webhooks, channels, routines, and all history — returns exactly as it was, including anything you had already disabled yourself.

When the timer elapses

Deletion is permanent and cannot be reversed. It begins by destroying the encryption keys for the workspace's secrets, which makes every stored secret unreadable immediately, and then removes the workspace's data context by context.

Restore stops being possible the moment that begins, not when it finishes. If you might want the workspace back, restore it before the date shown on the banner.

What we keep, and why

A deletion removes your workspace's data. A small, fixed set of records deliberately survives it — each because deleting it would break an obligation we have to you or to a regulator.

Record	Why it survives
billing.invoices	Invoices are financial records with tax and accounting retention requirements that outlive the customer relationship. Deleting a workspace never shortens one.
events.audit_entries	Security-category audit entries have a retention floor. Deletion is precisely when that floor matters — it is the record of who did what, including the deletion itself. Non-security entries age out normally.
events.event_log	Holds the workspace's own lifecycle record (archived, deleted) and the security events behind the same floor. The remainder ages out normally.
membership.lifecycle_requests	The record of the deletion: who asked, when, why, and what was destroyed. Your deletion certificate is a read of it. Deleting this with the workspace would erase the evidence that the deletion happened.

Nothing in that list contains your workspace's content — no secrets, no code, no project data, no configuration.

Account-level records are not touched by a workspace deletion. Your account's credit balance, credit ledger, spending limits, and settlement statements belong to the account, not to any one workspace, and deleting a workspace never draws them down.

Closing the whole account

Deleting your last workspace does not close your account. The account survives with zero workspaces, your billing relationship continues, and you can create a new workspace whenever you like. Ending the relationship is a separate, deliberate action.

curl -X POST https://api.orunbase.com/v1/workspaces/ws_a1b2c3d4/close \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"confirm": "acme"}'

Closing schedules every workspace in the account for deletion, then the account itself — each with its own 30-day timer, each restorable individually until its own date. Nothing is destroyed when the call returns. Owners only, and you type the account slug to confirm.

A few things follow from "each workspace keeps its own timer":

• A workspace you had already scheduled for deletion keeps its earlier date. Closing the account never pushes a deletion further out than you asked for.
• A workspace you had parked (archived with no timer) gets one. Otherwise it would sit there indefinitely and the account could never finish closing.
• The account is deleted last, only once every workspace under it is gone.

If any workspace cannot be scheduled, the call stops and returns 409 naming them — and your account is left open rather than half-closed. Workspaces already scheduled by that attempt keep their timers; Keep it archived cancels any of them individually.

Your subscription ends when the account is actually deleted, not when you close it — the same rule as a single workspace.

What survives a closed account

The account-level records above — the ones a workspace deletion deliberately never touches — are keyed to the account rather than to any workspace, so deleting the workspaces does not remove them. They survive the account too.

Record	Why it survives
billing.credit_balances	Your remaining credit balance, kept so a closure that turns out to be a mistake — or a dispute about what was left — can be settled against a real number rather than a recollection.
billing.credit_buckets	The individual grants behind that balance: what was bought or granted, when, and when each expires. A balance nobody can account for is not evidence of anything.
billing.credit_ledger	Every movement in and out of the balance. This is the audit trail that makes the closing figure checkable rather than asserted.
billing.meter_statements	The periodic usage statements your invoices were computed from. They are kept for the same span as the invoices themselves, which outlive the customer relationship.
billing.spending_limits	The caps that were in force, kept so a question about a charge can be answered against the limits that actually applied at the time.
membership.teams	Teams are defined at the account level and can be granted across several workspaces, so they are not any one workspace's data; the closed account's definitions remain with its billing records.
membership.team_owner_handles	The owner-handle aliases those teams answered to, kept with them so a historical grant or an audit entry naming a handle can still be read back.

Each closed workspace's deletion certificate lists these alongside the ordinary retained categories, so the disclosure is on the record and not only in this page. Deleting a child workspace never touches them and its certificate does not list them — they are the account's records, not that workspace's.

When support can change the timer

Two things you cannot do yourself, and support can — each on a written request, each recorded with a reason, and each stated on your deletion certificate.

Delete it sooner. If you need a workspace gone before its 30 days are up, support can bring the date forward. There is deliberately no button for this: a countdown you can skip with the same click that started it is not a safety net. Even then, nothing is destroyed at the moment support acts — the workspace simply becomes due, and stays restorable until the deletion actually begins.

Hold it indefinitely. If a workspace's data is subject to a legal hold — litigation, a dispute, a preservation order — support can mark it so, and it is then never permanently deleted, whatever its timer says. A hold has no expiry date, on purpose: a hold that lapsed on a date could destroy data in the middle of the matter it was placed for. Your own deletion date is untouched and still there when the hold is lifted.

A hold stops the permanent deletion and nothing else. A held workspace can still be archived, deleted, restored, and used exactly as normal.

Proof of deletion

curl https://api.orunbase.com/v1/workspaces/ws_a1b2c3d4/deletion/certificate \
  -H "Authorization: Bearer $TOKEN"

The certificate states what was deleted — per context, with row counts and timestamps — what was retained and on what basis, and when each step happened. It is built from the record of the statements that actually ran, not from a description of what deletion is supposed to do.

It also names any support intervention: if the date was brought forward, the certificate says when and by whom and quotes the written request; if a legal hold is in force, it says so and gives the reason, which is the answer to "why has this not deleted yet?".

It reports complete: false if any part of the deletion did not finish, rather than rounding up. Read it against the account that owned the workspace: after a deletion the workspace itself has no members left to authorize the request.

API

Verb	Route
Archive	POST /v1/workspaces/{id}/archive
Delete (archive + timer)	DELETE /v1/workspaces/{id} — body {"confirm": "<slug>"}
Restore	POST /v1/workspaces/{id}/restore
Keep it archived	POST /v1/workspaces/{id}/cancel-deletion
Current state	GET /v1/workspaces/{id}/lifecycle
Certificate	GET /v1/workspaces/{id}/deletion/certificate
Close the account	POST /v1/workspaces/{accountId}/close — body {"confirm": "<account slug>"}

GET …/lifecycle returns purgeAfter: null for a workspace that is archived with no timer, or a date for one scheduled for deletion. It also returns restoreCaveats — the same list as above, so you never have to reconstruct it.