Retention and deletion
How long Sess keeps what you send, and what happens when that time is up.
On this page
In the preview today
- Trial Sessions: the human link accepts answers for 1 hour after creation (
action_expires_at). The result can be read with the management credential for 24 hours after that (result_available_until); afterwards the trial API no longer returns it. A trial creates new Sessions for 24 hours (trial_expires_at). - Sessions created with your API key: a developer account's API key follows the free workspace's periods: the human link expires 7 days after the Session is created, and the Session is deleted 7 days after it ends. The developer account itself does not expire. Draft — lands with P1 increment 2
- Operator-key Sessions (the deployment's own key, held by the Sess team and never issued to developers): each human link expires 30 days after its Session is created, and the Session is deleted 30 days after it ends. After the link expires it shows only the generic "not found" page; owner access to the Session, its revisions and its Events is unchanged until the Session is deleted (below).
- Expiry stops new input. It never discards a response that was already accepted.
- Claiming a trial into your account does not change these deadlines or its deletion. Draft — lands with P1 increment 2
- Used or expired sign-in links and ended account sessions (expired or signed out) are deleted automatically within a day. Your account, its workspace and its API keys, including revoked and expired ones in your key history, are kept. Deleted data can persist in database backups until those backups expire. Draft — lands with P1 increment 2
- Once a trial Session's
result_available_untilhas passed, Sess deletes its content, its accepted result and its receipt. The server runs this deletion periodically, so it can follow the deadline by a short time. Afterwards the Session reads as not found, and Sess keeps only a record without content, for example that the Session existed, its trial, its final status, and when it was created and ended. Deleted data can persist in database backups until those backups expire. - An owner-key Session (one created with an API key or the operator key) ends when you complete it or when its human link expires, whichever comes first. When its retention period after the end has passed (above: 7 days for a developer account's API key; Draft — lands with P1 increment 2 30 days for the operator key), Sess deletes its content, its accepted results and their receipts, and cancels any webhook delivery still outstanding. Like the trial deletion it runs periodically, so it can follow the deadline by a short time. Afterwards the Session reads as not found on every owner route, and Sess keeps only a record without content: that the Session existed, its workspace, its final status, and when it was created, completed and ended. A webhook delivered before the deletion cannot be recalled. Deleted data can persist in database backups until those backups expire. This deletion applies to owner-key Sessions created after it was introduced (see the changelog); Sessions created before then are not deleted automatically, because retention changes are never retroactive.
- Each accepted result's receipt stays verifiable for at least 30 days after acceptance and, for a Session that Sess deletes automatically, at least until its result is deleted. Receipts are never re-signed, so two kinds keep their original expiry of 30 days after acceptance even though the result can stay readable longer: receipts issued before owner-key Sessions were deleted automatically, and receipts of owner-key Sessions created before then, which are not deleted automatically. A verifier that checks such a receipt against the current time can report it as expired while its result is still readable.
- The preview is for testing: send only fabricated or non-sensitive data.
- Sess can revoke a single Session's link immediately on request. Revocation survives restarts and cannot be undone.
- Sess redacts human link tokens, owner keys and management credentials from its application logs and telemetry.
Three separate deadlines
Draft — lands with P1 increment 2 Planned; not available on the current API.
Every Session gets three deadlines, each documented and checked by the server:
- Action deadline: after it, the page accepts no new input.
- Delivery deadline: until it, an already accepted result can still be delivered and retrieved.
- Purge time: Sess deletes the Session's content and results, and cancels any outstanding delivery that would carry them.
Retention by plan
Draft — lands with P1 increment 2 Planned; not available on the current API.
| Plan | Live Session | Result and content kept |
|---|---|---|
| Free workspace | Up to 7 days | 7 days after the Session is completed or its link expires, whichever comes first |
| Paid pilot (planned) | Up to 30 days | 30 days after the Session is completed or its link expires, whichever comes first |
Every developer workspace is on the free workspace today, and the server enforces its periods for each Session. The paid pilot is not available yet. The periods apply to individual Sessions, not to your account, which does not expire.
Retention changes apply only to Sessions created after the change is published, never retroactively.
What remains after deletion
Draft — lands with P1 increment 2 Planned; not available on the current API.
After purge, Sess keeps only minimal records without content: for example that a Session existed, when it ended, and whether it counted towards your usage. These keep invoices reconcilable. Deleted data can persist in database backups until those backups expire.
Draft — lands with P1 increment 3 Planned; not available on the current API.
The backup retention period is published here before the public beta.