Data retention and deletion
While the account exists
Account rows stay in SQLite while the account exists. This build does not publish a backup schedule. It does not promise that a deleted row can be restored. There is no separate archive kept after deletion.
Translation history
History is capped by the plan: 50 rows with no subscription, 2,000 on Individual, 5,000 on Team, and 10,000 on Business. Newer translations can push older ones out of that cap. The history API returns at most 200 rows even when more are stored. An export asks for the rows the server still has, not only the 200 shown in the app.
Deleting one translation removes that row. Deleting all translation history removes the translation rows for the account, the favourites that pointed at them, and the idempotency copies used to avoid counting a repeat within 10 minutes. The account remains. The password is not required for history deletion. The word count already recorded for the month is not rewritten back to zero.
Sessions and reset codes
A sign-in without Remember me lasts 24 hours. A sign-in with Remember me lasts 30 days. Creating an account starts a 30-day session. Sessions already stored keep the expiry they have. Signing out deletes that session’s token hash. Sign out of all devices deletes every session for that account and does not delete the account. A password reset code lasts 30 minutes. Changing the password through a reset deletes sessions for that account.
The application log is the process output of method, path, and status. This draft does not set a retention period for that output on the operator’s computer. Request addresses used for the short rate limit are kept in memory for about a minute and are not written to SQLite.
Consent rows stay until the account is deleted. They are not updated when a policy version changes.
Deleting the account
DELETE /v1/me requires the current password. A wrong password leaves the account in place. A correct password deletes the user row. Related rows are removed with it: sessions, reset codes, translations, favourites, subscriptions stored in SQLite, the Stripe customer link stored in SQLite, usage counts, idempotency rows, rate windows, product events, and consent records.
That deletion does not cancel a Stripe subscription by itself and does not delete the customer inside Stripe. If a paid subscription is still running, cancel it in the billing portal first, or write to zenvorafounder@gmail.com and understand that this mailbox is not read by the server.
Export
GET /v1/me/export returns a JSON file for the signed-in account. It includes profile settings, consent rows, the subscription summary stored in SQLite, translation history, usage counts, and the two kinds of product events. It does not include the password or the password hash. On the website, the button downloads that file only when the account service accepts the session. In the app, Settings uses the same request. If the request fails, nothing is described as exported.
Copies elsewhere
MyMemory, OpenAI, Stripe, Vercel, and Google may keep their own copies or logs under their own rules. Deleting data in ZENVORA does not reach those copies. This draft does not state their retention periods.