PATCH /v1/volumes/:id — set or clear a volume's storage cap (API key, org inferred from key).
Update a named volume's capacity limit or labels.
Path parameters
Volume id
Request body
New per-volume storage cap in GiB. Omitted = unchanged; null = clear the cap (back to no per-volume limit); a value sets it. A set value must be >= 1 and <= the org's storage cap.
Replacement label set. Omitted = unchanged; an object replaces the labels wholesale (an empty object clears them). Reserved-prefix keys are rejected.
Response
Volume updated
The volume's configured per-volume storage cap in bytes, or null when no cap is set (#496). Derived from the stored capacity_gib (the user's configured intent) — the effective ceiling is min(this, org cap).
What kind of volume this is — its storage source / role. The host volume is the org's single shared "host disk"; managed volumes are user-created, named, platform-provisioned (JuiceFS over our object store). (A future External variant — bring-your-own S3/GCS — is intentionally out of scope for now.)
User-defined labels (empty object when none set).
User-facing name. null for the host volume (it has no name; it's identified by kind).
Lifecycle status of a volume.
How a volume is physically backed — distinct from [VolumeKind] (ownership). Every volume is Block today; the enum exists so future backings can be added (and reported to the SDK) without another schema change.
Bytes currently used under this volume's subtree. null when usage is unavailable — the usage service is disabled or unreachable (list degrades gracefully rather than failing) — or on create/delete, which don't sample it.