Volumes Service API Reference

Reference · Updated Sep 2026

Coming from another cloud?

▸AWS·Amazon EBS volumes

Amazon EBS volumeshigh

Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
API via EC2 CreateVolume; differs from Cinder create_volume.

AWS docs ↗

▸Azure·Managed Disks

Azure Managed Diskshigh

Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

Azure docs ↗

▸DigitalOcean·API

DigitalOcean APIhigh

Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
Rate limits: 5000/hour, 250/minute.

DigitalOcean docs ↗

▸Google Cloud·Persistent Disk

Persistent Diskhigh

Uses Google Compute Engine REST API instead of OpenStack Cinder API.
Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

Google Cloud docs ↗

▸Hetzner·Cloud API

Cloud APIhigh

Proprietary REST API over HTTPS with Bearer token auth, not OpenStack Identity API (keystone) endpoints or mechanisms.
Base URL https://api.hetzner.cloud/v1/ with resource-specific endpoints (e.g., /servers) vs OpenStack service endpoints (nova, cinder).
No multi-project handling in single auth; separate per-project tokens vs keystone scopes/projects.
Missing identity/catalog endpoints; no service discovery via API.

Hetzner docs ↗

Volumes service API reference

The Block Storage API reference documents every Cinder endpoint with curl examples and request bodies.

See https://docs.openstack.org/api-ref/block-storage/. For error handling guidance, see the API error reference.

In these methods, \{project_id\} is the ID of the project or tenant, \{volume_id\} is the ID of the volume, and \{snapshot_id\} is the ID of the snapshot. These methods allow you to manage volumes and snapshots in the OpenStack Volumes service, including creating, listing, showing details of, updating, and deleting volumes and snapshots.

List volumes#

bash

GET /v3/{project_id}/volumes

List volumes with details#

bash

GET /v3/{project_id}/volumes/detail

The plain GET /v3/{project_id}/volumes returns a summary (id, name, and links) for each volume; the /detail variant returns the full body for each volume. GET /v3/{project_id}/snapshots returns details by default.

Show volume details#

bash

GET /v3/{project_id}/volumes/{volume_id}

Create a volume#

bash

POST /v3/{project_id}/volumes

Request body

JSON

{
   "volume": {
   "size": 1,
   "name": "volume_name",
   "description": "volume_description"
 }
}

Update a volume#

bash

PUT /v3/{project_id}/volumes/{volume_id}

Request body

JSON

{
 "volume": {
 "name": "new_volume_name",
 "description": "new_volume_description"
 }
}

Delete a volume#

bash

DELETE /v3/{project_id}/volumes/{volume_id}

List volume snapshots#

bash

GET /v3/{project_id}/snapshots

Show snapshot details#

bash

GET /v3/{project_id}/snapshots/{snapshot_id}

Create a snapshot#

bash

POST /v3/{project_id}/snapshots

Request body

JSON

{
 "snapshot": {
   "volume_id": "volume_id",
   "name": "snapshot_name",
   "description": "snapshot_description"
 }
}

Update a snapshot#

bash

PUT /v3/{project_id}/snapshots/{snapshot_id}

Request body

JSON

{
 "snapshot": {
   "name": "new_snapshot_name",
   "description": "new_snapshot_description"
 }
}

Delete a snapshot#

bash

DELETE /v3/{project_id}/snapshots/{snapshot_id}

Limits#

Query project quotas and current resource usage for block storage. The response contains rate (always empty on Antelope) and absolute (volume/snapshot quotas and usage).

Show project limits#

bash

GET /v3/{project_id}/limits

Response body:

JSON

{
  "limits": {
    "rate": [],
    "absolute": {
      "maxTotalVolumes": 500,
      "maxTotalSnapshots": 500,
      "maxTotalVolumeGigabytes": 200,
      "totalVolumesUsed": 3,
      "totalGigabytesUsed": 30,
      "totalSnapshotsUsed": 0
    }
  }
}

The values shown are the current project defaults; they can vary by project and by approved quota requests.

Key fields#

Field	Meaning
`rate`	Always `[]`. Application-layer rate limits are not active.
`maxTotalVolumes`	Maximum volumes allowed in this project.
`maxTotalSnapshots`	Maximum snapshots.
`maxTotalVolumeGigabytes`	Maximum total storage in GiB across all volumes.
`totalVolumesUsed`	Current volume count.
`totalGigabytesUsed`	Current total storage in GiB.
`totalSnapshotsUsed`	Current snapshot count.

For quota troubleshooting, see Quota and limits troubleshooting. For rate limit behavior, see API rate limits.

Volumes Service API Reference

Volumes service API reference

List volumes#

List volumes with details#

Show volume details#

Create a volume#

Update a volume#

Delete a volume#

List volume snapshots#

Show snapshot details#

Create a snapshot#

Update a snapshot#

Delete a snapshot#

Limits#

Show project limits#

Key fields#

See also#

See Also