Export everything
GET /account/export streams every row your workspace owns as newline delimited JSON. No support ticket, no waiting, no partial archive.
Export stays available while a workspace is suspended, unentitled or scheduled for deletion. Losing access to capacity never means losing access to your data.
A large workspace produces a large stream. Call the API directly with a personal API token rather than through the web origin proxy, which applies a per request timeout.
Delete the workspace
Deletion is confirmed, delayed and reversible. An immediate irreversible delete behind one click is a support incident waiting to happen.1
Request it
As the workspace owner, open Settings, go to Workspace and press Delete workspace. The dialog enables its action only once you type
DELETE. From the API, send POST /account/deletion with {"confirm":"DELETE"}. Anything other than the literal DELETE is refused.2
Nothing happens yet
The workspace keeps running for the grace period, seven days by default and set by
ACCOUNT_DELETION_GRACE_DAYS. Every member sees a banner on every page naming the earliest erasure date, and Settings shows who asked and when. GET /account/deletion reports the same.3
Change your mind
The owner presses Cancel deletion in Settings, or sends
DELETE /account/deletion. Nothing was removed, so nothing needs restoring. A member sees the status but cannot cancel it.4
Erasure
On the first retention run after the grace period ends, the workspace row is deleted and every tenant owned table cascades with it. The due date is therefore the earliest erasure, not an exact time.
What erasure removes
Everything the workspace owns: the workspace, its users, personal API tokens and invites, apps and groups, snapshots, tracked keywords, rankings, category ranks, reviews, listing changes, audits, audit scores, action items, webhooks, email alerts, the delivery log and alert events. An end to end test seeds a row in every tenant owned table, deletes the workspace, and asserts each one is gone. The same test fails if a future table is added without being covered, which is what keeps this list true rather than aspirational.What erasure does not remove
Three things survive, deliberately, and pretending otherwise would be dishonest.
Beyond the application:
- Your payment provider keeps its own records. Stripe retains payment and invoice data under its own legal obligations, and we cannot delete what a subprocessor is required to keep. Ask them directly.
- Backups contain deleted data until they rotate. This is the real deletion horizon and it is worth stating plainly: erasure removes your data from the live database immediately, and from backups after the backup retention window passes. The shipped schedule keeps 14 daily and 8 weekly archives, and the offsite copies default to the same window, so that window is 56 days. See Backups, which is where a deployment records its own window if it changed it.
- Server logs carry workspace identifiers, never your keywords or listings, and rotate with the hosting platform.
Retention while the workspace is alive
Every retention window is listed in the privacy policy and configured by theRETENTION_* variables in the configuration reference. A daily job prunes rows past their window.
Retention prunes by age. Deletion removes everything at once. They are separate paths, and neither one rewrites history: a pruned day is gone, never replaced by an estimate.
Self hosted
Everything above describes the code, so it applies to your own installation too. The endpoints are the same, the grace period is yourACCOUNT_DELETION_GRACE_DAYS, and the backup horizon is whatever your own backup schedule makes it. Nobody else holds a copy, because a self hosted deployment reports to nobody.