How encryption works
Every file is encrypted with its own per-file key, which is in turn wrapped by the user’s record key. Nothing is written to storage in the clear, and a file can only be decrypted through the vault. Because the file key is chained to the user’s record key, file storage inherits two properties of the PII vault:- Crypto-shredding on erasure — deleting the user destroys the record key, which renders all of that user’s files permanently unrecoverable. This is the mechanism behind GDPR “right to erasure” for attached documents.
- Shared key management — the same key rotation, Shamir’s secret sharing, multi-tenancy, and access control apply to files as to any other record.
| Backend | Typical use |
|---|---|
| Local disk | Single-node or on-prem deployments |
| Amazon S3 | AWS deployments |
| Google Cloud Storage | GCP deployments |
| Azure Blob Storage | Azure deployments |
API operations
| Endpoint | Purpose |
|---|---|
FileCreate | Store an encrypted file for a user |
FileGet | Retrieve and decrypt a file |
FileListUserFiles | List a user’s files (metadata only) |
FileDelete | Remove a file’s object and metadata |
mode (login, token, email, phone, or custom) and the matching identity.
Store a file
File content is supplied as a base64-encodedfiledata field. The MIME type is auto-detected when mimetype is omitted.
"duplicate": true.
Retrieve a file
Select a file byfileuuid (preferred) or by filename — when selecting by name, the most recently created file with that name is returned. By default the content comes back as a base64-encoded filedata field:
"raw": true to receive the decrypted bytes with the appropriate Content-Type and Content-Disposition headers instead of a JSON envelope.
List a user’s files
FileListUserFiles returns metadata only — never file content:
Delete a file
FileDelete removes both the stored object and its metadata:
Retention and expiration
Files support the same expiration model as tokens. Setslidingtime for a relative retention window (e.g. 30d, 1y) or finaltime for an absolute cutoff (e.g. 90d, 2026-01-01). This lets you enforce document retention policies automatically instead of tracking expiry in your own application.