Export everything
GET /account/export streams every row your workspace owns as newline delimited JSON. No support ticket, no waiting, no partial archive.
Credential material and the state that goes with it stays in the database. A member’s pending recovery link, its expiry, the counter that signs their sessions out, and the identifiers of an open billing checkout are never written to the archive, whoever asks for it and whichever credential they use. The archive is the workspace’s data; a parser should not expect those columns on the
user and workspace rows.
Export stays available while a workspace is suspended, unentitled or scheduled for deletion. Losing access to capacity never means losing access to your data.
The response is sent in chunks as the rows are read. The manifest counts each table when the download starts, and the rows are then read in pages. A complete download ends normally and holds every row that existed for the whole download, each exactly once. A row written or deleted while it runs, for example by the daily run or the retention job, can add or remove a line, so the line count of a table matches the manifest exactly when nothing wrote to the workspace during the download. If the server cannot finish, for example because the client stops reading for a minute, it closes the connection instead of ending the response, so a client reports a broken transfer rather than a short file that looks whole. When a script depends on a complete archive, check that the download ended normally, compare the line counts with the manifest, and download again at a quiet time if they differ.
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. The workspace of the platform operator answers 409 Conflict while other accounts exist, as Deleting the operator workspace explains.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. Once the retention run has started releasing the workspace at Stripe, cancelling answers 409 Conflict: the subscription may already be gone, so erasure finishes. If Stripe could not be reached, the run lets go and cancelling works again.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. A workspace that pays is released at Stripe first: its Stripe customer is deleted, which cancels every subscription so nothing is charged again. If Stripe cannot be reached, the workspace waits for the next run rather than being erased while its subscription still bills.
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, followed top charts, 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
Five 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. When a plan was sold through Link, Link keeps the receipt and invoice as the seller of record. 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.