Skip to content
View as Markdown

Flavors API Reference

Reference · Updated Sep 2026

Coming from another cloud?

▸AWS·Instance Types

Instance Typeshigh

  • Fixed predefined configurations only; no custom flavor creation.
  • Extensive families for GPU/HPC/ARM etc.
  • InstanceType as string param in API, not ID reference.
  • Tied to specific hardware generations (Nitro/Xen).
AWS docs ↗
▸Azure·VM sizes

VM sizeshigh

  • Predefined hardware-optimized series (e.g., D-family general purpose) with complex naming (e.g., Standard_D4as_v5), not user-defined vCPU/RAM like OpenStack flavors.
  • Sizes listed via API /providers/Microsoft.Compute/locations/{location}/vmSizes, region-specific availability.
  • Includes accelerator features (GPU, FPGA) baked into sizes, unavailable in basic OpenStack flavors without extensions.
  • Cannot create custom sizes; selection from catalog, limiting flexibility vs OpenStack flavor creation.
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·Machine types

Machine typeshigh

  • Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
  • Custom types +5% premium for N/E series; no such billing in OpenStack.
  • Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.
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 ↗

Flavors API reference

See https://docs.openstack.org/api-ref/compute/.

Use these endpoints to create, list, update, and delete flavors, and to manage access to private flavors. The \{flavor_id\} and \{project_id\} in the URLs are placeholders for the actual flavor and project IDs.

List flavors#

bash
GET /flavors

Returns a summary listing: each flavor's id, name, and links only.

List flavors with full details#

bash
GET /flavors/detail

Returns the full flavor object (ram, vcpus, disk, swap, ephemeral, rxtx_factor, is_public, and the disabled flag) for every flavor in a single request. Use this instead of GET /flavors followed by per-ID lookups when you need more than id and name.

Show flavor details#

bash
GET /flavors/{flavor_id}

Create a flavor#

bash
POST /flavors

Update a flavor#

bash
PUT /flavors/{flavor_id}

Updating a flavor is admin-only and returns 403 Forbidden for non-admin tokens.

Delete a flavor#

bash
DELETE /flavors/{flavor_id}

List flavor access (for private flavors)#

bash
GET /flavors/{flavor_id}/os-flavor-access

Add flavor access (make a flavor private and grant access to specific projects)#

bash
POST /flavors/{flavor_id}/action with {"addTenantAccess": {"tenant": "{project_id}"}} in the request body

Remove flavor access (revoke access from specific projects)#

bash
POST /flavors/{flavor_id}/action with {"removeTenantAccess": {"tenant": "{project_id}"}} in the request body

Quick answers

See all Compute FAQs

See Also

Flavors Console

Shares: Flavors, Compute

→

Compute Console

Shares: Flavors, Compute

→

Compute Service API Reference

Shares: API, Compute

→

Images Service API Reference

Shares: API, Compute

→

Instances API Reference

Shares: API, Compute

→
Was this page helpful?