Preview — pending review
This reference is generated from the platform API contract and is still under review. Operations, fields, and descriptions can change before publication.
Which product modules are available in a region
Answers, for the selected platform region, which product modules the platform actually
offers there — so the console can hide a module it cannot deliver instead of rendering a
menu item whose every request fails. A module is available IFF the region's OpenStack
catalog (and, for VPN, its neutron extension list) provides everything the module needs,
the control plane can drive those services, AND an operator has not switched the module
off for this region. An operator may switch a module OFF as a product decision but can
NEVER switch one ON that the region does not serve, so available: true always means the
region really provides it.
Returns an entry for EVERY module, always — never a partial map. A client must never have
to read "absent" as "fine": that is exactly how a gating gap becomes a broken button.
WHAT THIS DELIBERATELY DOES NOT RETURN: no OpenStack service type, no endpoint URL, no
discovered version, no operator note, no provider or OpenStack region identity — and no
distinction between "not sold here" and "the region cannot do it". All of that is
operator information (same reasoning as .../compute/flavors/availability, which hides
raw host capacity behind a boolean). reason is a token from a small server-side
vocabulary — not_offered_in_region today — typed as a plain string rather than a closed
enum so a token added later degrades to a generic sentence instead of failing to parse
and silently dropping the gating for every module.
available is NOT a reservation: the create paths enforce the same rule authoritatively,
and an operator can close a module between this read and a create.
Validation: region must be shape-valid and resolve to a region bound to an ENABLED
provider, else 404 NOT_FOUND.
Async & state: Synchronous read; no state change.
Errors: 401 unauthenticated; 404 when the region is unknown, bound to nothing, or its
provider is disabled — ONE answer for all three, so the response discloses nothing about
which (and 404 rather than an empty list, since an empty modules array is
indistinguishable from a region where nothing is on, and a client should re-read
GET /regions instead of rendering a fully-greyed region); 500 read-model failure.
Idempotency/Concurrency: Safe. NOT cacheable — the answer is a gate and changes the
moment an operator flips an override, so the response is sent Cache-Control: no-store.
bearerTokenAuthorizationBearer <token>An API token (pc_live_…) or a service-account key (sak_live_…), created in Identity & Access Management and sent as Authorization: Bearer <token>. Requests are rate limited per credential and per tenant: every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and a refused request gets 429 RATE_LIMITED with Retry-After.
region*stringThe platform region code whose module availability is being read.
^[a-z][a-z0-9-]{1,39}$One availability verdict per product module for the resolved region.
application/json- response
Per-module availability for one region, from GET /regions/{region}/capabilities. modules carries an entry for EVERY product module, sorted by key — never a partial map, because a client that read "absent" as "fine" would render a module the region cannot serve.
region*RegionIdPlatform region code (a DNS-label-shaped slug, e.g. ist-1). No longer a closed enum: the set of valid region codes is operator-managed in the platform-region registry, so this carries only a shape guard. The authoritative set of activated regions is read from GET /regions; invalid-shape codes are VALIDATION_FAILED and codes absent from the registry are rejected at the resolving endpoint.
^[a-z][a-z0-9-]{1,39}$modules*array<>curl -X GET "https://example.com/regions/string/capabilities"{ "region": "string", "modules": [ { "module": "string", "available": true, "reason": "string" } ]}