> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parser-app.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Your data

> How your tenant's data is isolated and encrypted, how long it is kept, how to export it, and how a tenant is deleted.

## Isolation and encryption

Every record belongs to one tenant, and the database itself refuses one tenant's rows to another (row-level
security, enforced for the roles that serve requests, which cannot switch it off). Each tenant has its own data
key (AES-256-GCM), itself encrypted under the platform's master keys:

* the documents and raw emails you send are encrypted with it before they reach storage;
* job requests and results, cached reads, stored model answers, webhook event payloads, corrections and email
  subjects are encrypted with it in the database;
* mailbox logins, integration credentials and webhook secrets are encrypted under the master keys.

Destroying a tenant's data key makes whatever a backup still holds of it unreadable.

## Retention

Every tenant has a retention period, `retention_days`, set when the tenant is created. Jobs, their files and
the emails that fed them are erased automatically once they are older than it; a queued or running job is never
erased. `null` keeps everything until you delete it.

```bash theme={null}
curl -sS "$API/v1/tenant/settings" -H "X-API-Key: $ADMIN_KEY"
curl -sS -X PATCH "$API/v1/tenant/settings" -H "X-API-Key: $ADMIN_KEY" -H "Content-Type: application/json" \
     -d '{"retention_days": 365}'
```

`$ADMIN_KEY` is a key with `settings:manage`; an owner's or admin's access token works too, as
`Authorization: Bearer`. To erase one job, or every job of one of your end users, at any time, see
[Erasure](https://docs.parser-app.com/concepts/jobs.md#erasure).

## Export

`GET /v1/tenant/export` (`settings:manage`) streams one ZIP of everything your tenant holds:

| Path | Holds |
| - | - |
| `data/<table>.ndjson` | Your rows of every table, one JSON object per line: jobs with their requests and results, corrections, mailboxes, emails, webhook endpoints and events, integrations, usage, the audit log. |
| `files/<job id>/<nnn>_<name>` | Each job's input files, as sent. |
| `emails/<email id>.eml` | The raw messages kept. |
| `manifest.json` | What was written, and what was left out. |

Never in it: API key hashes, mailbox and integration credentials, webhook and integration secrets, and the data
key. Cached reads and indexes are left out too: they are rebuilt from the inputs. Every export is recorded in the
audit log. The ZIP is streamed as it is written, so it has no `Content-Length`; a large tenant's export takes a
while.

```bash theme={null}
curl -sS "$API/v1/tenant/export" -H "X-API-Key: $ADMIN_KEY" -o tenant-export.zip
```

## Deleting a tenant

A tenant is deleted by the Parser platform team, on your request. The moment it starts, every API key and sign-in
of the tenant is refused and no new work starts. Then every job, file, email, mailbox, webhook, integration and
usage record is erased, and the tenant's data key is destroyed. Export first: nothing can be recovered afterwards.

The audit log is kept: it is append-only, and it records the deletion itself. Mail connections at the provider
(a Gmail watch, a Microsoft 365 subscription, an app password) are not revoked there; remove the app's access in
your Google or Microsoft admin console.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.