1. The problem in plain terms
Our accouant is billed for ~31.8 TB of cloud recording storage and it keeps growing ~0.26 TB/day. However, when we enumerate every recording via the API
across all dates, the actual recording files add up to less than 2.5 TB. We cannot find, list, or delete the other ~29 TB — the storage is billed but the
files are not reachable through any recording API. We believe a large volume of recordings were deleted from the recording listings but their storage was
never actually freed (orphaned/un-purged storage).
- Evidence (all from your own APIs)
- GET /accounts/me/plans/usage → plan_storage_usage: “5 TB”, plan_storage_exceed: “26.71 TB”, max_exceed_date: 2026-07-12 → total ≈ 31.8 TB.
- GET /report/cloud_recording daily usage, showing steady growth:
- 2026-02: 2.46 TB → 2026-03: 2.84 TB → 2026-04: 7.37 TB → 2026-05: 14.21 TB → 2026-06: 21.8 TB → 2026-07: 29.09 TB (~+7 TB/month since March 2026).
- GET /accounts/me/recordings (account-wide, with account:read:admin), swept across all date ranges 2023–2026:
- Recent recordings average ~2 MB each; one full week (2026-07-06 to 07-12, 36,471 recordings) sums to only ~70 GB of actual files.
- recording_files, participant_audio_files (~0.1–0.2 MB per meeting), and participant_video_files are all tiny.
- Old years return almost nothing (2024: 0 records; 2025: a handful).
- Trash: trash_type=recording_file holds ~750 GB (July only); June and earlier return 0 — so trash is auto-purging normally and is not where the 31 TB
sits. - When we call DELETE /meetings/{meetingUUID}/recordings?action=delete using the correct meeting UUID, we receive HTTP 404 (“recording does not exist”) for
the vast majority — yet billing continues to count these toward the 31.8 TB.
- What we have already ruled out
- Not stale total_size (it matches actual file sizes in aggregate).
- Not participant-audio files (verified via single-meeting GET — tiny).
- Not trash (auto-purges after 30 days; only ~750 GB present).
- Not deactivated hosts (inactive/pending users = 0).
-
What we are asking Zoom to do
-
Reconcile the gap: billing shows ~31.8 TB, but recordings reachable via API total <2.5 TB. Please identify where the remaining ~29 TB physically lives.
-
Explain the 404s: why do DELETE …/recordings calls with the correct meeting UUID return 404 while the storage is still billed?
-
Server-side purge: please locate and permanently purge the orphaned/un-freed cloud recording storage that we cannot reach via API.
-
Confirm root cause: is this a known behavior where recordings removed from listings (or individually deleted files) are not actually freed from storage?
If so, how do we prevent recurrence? -
Impact & urgency
We are paying for 26.71 TB over quota and it grows ~7 TB/month. We have already fixed our own deletion logic to stop future accumulation, but we cannot
reclaim the existing ~29 TB because the API will not surface or delete those files.