Skip to content

Quota and retention

Storage is metered per tenant and per application, and nothing is kept forever by accident. This page explains the three ceilings, how usage is counted, and the retention of everything that expires. It is for administrators, for backend developers who handle a full quota, and for evaluators.

Ceiling Set by Default
Tenant quota A platform administrator, in the console’s platform administration, for every application of the tenant together. It can also be unlimited 50 GiB
Application quota (quota_bytes) The tenant, in the application’s settings. It must fit in the tenant quota minus the other applications’ quotas None: the tenant quota applies
Largest file (max_file_size_bytes) The tenant, per application, within the tenant’s ceiling and the platform maximum of 5 GiB 2 GiB

A platform administrator can also set a tenant’s allowed types, switch public files and share links off for it, and suspend it: a suspended tenant keeps reading, and every new upload answers 403 tenant_suspended. Lowering a quota below the current usage deletes nothing; it blocks new uploads until usage drops.

Counted Not counted against the quota
The bytes of every kept version of every file, the trashed ones included Renditions (they are the service’s cost)
The declared size of every open upload ticket (a reservation)

A ticket reserves its declared size the moment it is created, so two uploads cannot both squeeze into the last free gigabyte. Completion turns the reservation into usage at the real size; an abort or an expired ticket releases it. A ticket that does not fit answers 413 quota_exceeded with the numbers:

{ "status_code": 413, "error": "quota_exceeded", "message": "…", "quota_bytes": 53687091200, "used_bytes": 53600000000, "reserved_bytes": 80000000 }
Route Answers Who
GET P/usage bytes, rendition_bytes, reserved_bytes, trashed_bytes, files, versions, quota_bytes, tenant_quota_bytes, tenant_used_bytes, by_kind, by_folder, and daily: the last 30 days files.audit.read or files.settings.manage; any machine scope
GET /tenants/:tenant_id/usage The tenant’s quota and use, and each application’s bytes and quota Either administration key in any application of the tenant; a machine client of the tenant
GET P/folders/:folder_id/usage Bytes, files and folders under one folder view on the folder

The service counts the stored bytes again every night and corrects any drift; a correction of more than a small margin is written to the audit log. It then takes the day’s snapshot of each application and tenant (bytes, renditions, trash, open uploads, files, versions, bytes by kind, the quota in force), which daily and the platform’s usage trends read. A day without a snapshot is missing from the series, never zero.

What Kept Then
Trashed files and folders trash_retention_days, default 30 days (0 to 365; 0 purges at once) Purged: bytes deleted, quota released, audit row file.purged
Old versions max_versions (default 10) and version_retention_days The oldest non-current, non-pinned ones are pruned
Upload tickets never completed Their lifetime: 1 hour single, 24 hours multipart Aborted, the reservation released, the pending file removed
Share links Until expires_at They answer share_gone
The audit log 365 days Deleted
Daily usage snapshots 400 days Deleted

Purging on demand: POST P/files/:file_id/purge deletes a file at once (with delete and files.manage, or as the owner when owner_can_purge is on), and POST P/trash/empty empties the trash (files.manage). Both are irreversible.

A file under a legal hold is the exception to every row above: it is never purged and its versions are never pruned while the hold is in force. Purging it answers file_on_hold, and emptying the trash leaves it (and its folder) there; the job’s result counts it as held.