HTTP API Reference for Momento Capacity Pools
Momento provides an HTTP API interface for managing Capacity Pools. This API lets you create, describe, update, list, and delete Capacity Pools programmatically, discover available capacity offerings, and scrape their utilization metrics.
A Capacity Pool is a provisioned unit of dedicated Valkey capacity. The available capacity
for a pool is the sum of Valkey's maxmemory as configured across all primary nodes. Replicas
enable failover and improve read throughput, but do not increase a pool's available capacity.
You choose how the Pool is sized, either explicit mode (Cluster), in which you specify the exact instance type, shard count, and replicas per shard, or managed mode (Flex), in which you give capacity and replication bounds and Momento sizes the Pool within them. Momento owns the underlying lifecycle and health of the Pool. Each Pool can host Databases, which share its compute and memory.
Momento Cache is available in limited preview. Request access before calling this API.
The Momento platform is region-based with endpoints specific to each region. To view a list of supported regions and their endpoints, click here.
Authentication
You will need a Momento API Key generated via the Momento console. Momento API Keys control access to the Momento services and can be set to expire.
The API Key must be provided in the Authorization header.
Capacity Pool API
The Capacity Pool API lets you create, describe, update, list, and delete Capacity Pools, discover the capacity offerings available to your account, and scrape utilization metrics.
Provisioning
A Capacity Pool's capacity is described by a provisioning object. The object nests its configuration under a single key that names the provisioning mode. Exactly one mode key must be provided, and unknown fields are rejected. Two modes are available:
explicit(Cluster) — you specify the instance type, shard count, replicas per shard, and AZ placement directly.managed(Flex) — you specify capacity and replication bounds, and Momento sizes the pool within them.
A pool's mode is fixed when it is created. Switching an existing pool between modes is not supported today.
In both modes, zones are availability-zone IDs (for example, use1-az1), not zone names — an AZ ID maps to the same physical zone across accounts.
Explicit mode
In explicit mode you specify the pool's shape directly:
{
"explicit": {
"instance_type": "r7g.xlarge",
"shard_count": 3,
"replicas_per_shard": 1,
"zones": ["use1-az1", "use1-az2"]
}
}
| Field | Required? | Type | Description |
|---|---|---|---|
| explicit | yes | Object | The explicit-mode provisioning configuration. Exactly one mode key must be provided. |
| explicit.instance_type | yes | String | The instance type for the pool's nodes (for example, r7g.xlarge). |
| explicit.shard_count | yes | Integer | The number of shards in the pool. |
| explicit.replicas_per_shard | yes | Integer | The number of replicas per shard. |
| explicit.zones | yes | Array<String> | The availability-zone IDs across which the pool's nodes are placed. Must contain at least one zone. |
Managed mode
In managed mode you specify bounds for available capacity and replication, and Momento sizes the
Pool within them. Set a dimension's minimum equal to its maximum to pin it to an exact value:
Flex offers Standard and Performance capacity families. The Performance family provides additional throughput and compute. Use the discovery API to confirm which families are available in a region.
{
"managed": {
"capacity": {
"min_gib": 32,
"max_gib": 128
},
"replication": {
"min_replicas_per_shard": 1,
"max_replicas_per_shard": 2
},
"zones": ["use1-az1", "use1-az2"],
"family": "standard"
}
}
| Field | Required? | Type | Description |
|---|---|---|---|
| managed | yes | Object | The managed-mode provisioning configuration. Exactly one mode key must be provided. |
| managed.capacity | yes | Object | The Pool's available-capacity bounds, in GiB. |
| managed.capacity.min_gib | yes | Integer | The minimum requested available capacity, in GiB. Set equal to max_gib to pin capacity. |
| managed.capacity.max_gib | yes | Integer | The maximum requested available capacity, in GiB. |
| managed.replication | yes | Object | The pool's replication bounds. |
| managed.replication.min_replicas_per_shard | yes | Integer | The minimum replicas per shard. Set equal to the maximum to pin replication. |
| managed.replication.max_replicas_per_shard | yes | Integer | The maximum replicas per shard. |
| managed.zones | yes | Array<String> | The availability-zone IDs across which the pool's nodes are placed. Must contain at least one zone. |
| managed.family | no | String | The capacity family to use. When omitted, the Pool resolves to the cell default. The resolved family is always present in managed-mode responses. |
Because managed available capacity is quantized to the configurations available in the cell, the
available capacity you are granted may exceed min_gib. The last settled allocation is reported by
current_capacity_gib; target_capacity_gib reports the allocation the Pool is converging to and
differs only while a scale is in flight. Both fields use the same available-capacity quantity.
current_replicas_per_shard reports settled replication.
Capacity offering discovery
Discovery responses are scoped to the calling account and the region served by the API endpoint. Use them to determine the managed families and Cluster instance types the account can select.
List managed capacity families
GET /capacity_pool/families returns:
| Field | Type | Description |
|---|---|---|
| families | Array | The managed capacity families the calling account may select. |
| families[].name | String | The family name accepted by provisioning.managed.family. |
| families[].is_default | Boolean | Whether this is the cell's current default family. |
| families[].min_capacity_gib | Integer | The minimum supported capacity range, in GiB. |
| families[].max_capacity_gib | Integer | The maximum supported capacity range, in GiB. |
List Cluster instance types
GET /capacity_pool/instance_types returns an instance_types array containing the instance types
the calling account may provision in explicit mode. The array is sorted and is empty when the cell
offers no Capacity Pool instance types.
Select or reset a managed family
Set provisioning.managed.family to a family name when creating a managed Pool to pin that family.
If you omit the field, the Pool resolves and pins the cell's current default. A later default change
does not silently move an existing Pool.
On update, pass { "family": { "name": "<family>" } } under provisioning.managed to pin a
named family. Pass { "family": "cell_default" } to re-resolve and pin the then-current cell
default.
Status
A Capacity Pool has its own lifecycle status, surfaced at describe time:
| Status | Description |
|---|---|
| creating | The pool has been accepted and its backing capacity is being provisioned asynchronously. |
| active | The pool is fully provisioned and ready to serve Databases. |
| deleting | The pool is being torn down. |
These three values are the pool's complete status set. A pool stays active while its capacity converges to a requested change; there is no separate scaling or updating status. Progress, or a condition that blocks the change, surfaces as a diagnostic.
Diagnostics
Every Capacity Pool response includes a diagnostics field: an array of customer-actionable conditions affecting the pool (for example, insufficient capacity), derived from the underlying capacity at read time. The array is always present and is empty ([]) when there is nothing to surface.
Describe Capacity Pool returns active conditions plus recently-resolved ones; List Capacity Pools returns only active conditions.
Each diagnostic nests its details under a single key that names the kind of condition. Three kinds are defined.
The insufficient_capacity kind is raised when Momento cannot provision the requested capacity:
{
"insufficient_capacity": {
"state": "active",
"message": "Insufficient r7g.xlarge capacity in use1-az1.",
"instance_type": "r7g.xlarge",
"availability_zones": ["use1-az1"],
"first_observed_epoch_seconds": 1719360000,
"last_observed_epoch_seconds": 1719363600
}
}
The fields of an insufficient_capacity diagnostic:
| Field | Type | Description |
|---|---|---|
| state | String | Whether the condition is currently in effect (active) or recently cleared (resolved). |
| message | String | A human-readable summary suitable for surfacing directly to the customer. |
| instance_type | String | The instance type that could not be provisioned. |
| availability_zones | Array<String> | The availability zones the condition has been observed in during this episode. |
| first_observed_epoch_seconds | Integer | When the condition was first observed, in seconds since the Unix epoch. |
| last_observed_epoch_seconds | Integer | The most recent time the condition was observed. For an active diagnostic, how recently it was confirmed still in effect; for a resolved one, the last failure before it cleared. |
| resolved_epoch_seconds | Integer | When the condition resolved, in seconds since the Unix epoch. Present only on a resolved diagnostic. |
The scale_blocked_by_utilization kind is raised at propagation time when an update that passed request-time preflight can no longer be applied — the pool's current data no longer fits the requested configuration, or its usage can't currently be verified. The stored request is retried automatically and applies once it fits (or is superseded by another update):
{
"scale_blocked_by_utilization": {
"state": "active",
"message": "The requested configuration is smaller than the pool's current data; retrying until it fits.",
"requested_shard_count": 6,
"requested_instance_type": "r7g.xlarge",
"data_approx": "42 GB",
"capacity_approx": "32 GB",
"first_observed_epoch_seconds": 1719360000,
"last_observed_epoch_seconds": 1719363600
}
}
The fields of a scale_blocked_by_utilization diagnostic:
| Field | Type | Description |
|---|---|---|
| state | String | Whether the condition is currently in effect (active) or recently cleared (resolved). |
| message | String | A human-readable summary suitable for surfacing directly to the customer. |
| requested_shard_count | Integer | The requested shard count that isn't landing. |
| requested_instance_type | String | The requested instance type that isn't landing. |
| data_approx | String | A rounded total of the pool's current data. Present only when the data doesn't fit; absent when usage can't be verified. |
| capacity_approx | String | A rounded total of what the requested configuration can hold. Present only when the data doesn't fit. |
| first_observed_epoch_seconds | Integer | When the condition was first observed, in seconds since the Unix epoch. |
| last_observed_epoch_seconds | Integer | The most recent time the condition was observed. |
| resolved_epoch_seconds | Integer | When the condition resolved, in seconds since the Unix epoch. Present only on a resolved diagnostic. |
The capacity_limit_reached kind is raised when a managed pool's utilization calls for growth but the pool is already at its configured maximum capacity. It remains active until you raise the ceiling or usage drops:
{
"capacity_limit_reached": {
"state": "active",
"message": "The pool has reached its configured capacity limit.",
"max_gib": 128,
"utilization_percent": 92,
"first_observed_epoch_seconds": 1719360000,
"last_observed_epoch_seconds": 1719363600
}
}
The fields of a capacity_limit_reached diagnostic:
| Field | Type | Description |
|---|---|---|
| state | String | Whether the condition is currently in effect (active) or recently cleared (resolved). |
| message | String | A human-readable summary suitable for surfacing directly to the customer. |
| max_gib | Integer | The configured capacity ceiling, in GiB, that the pool has reached. |
| utilization_percent | Integer | Utilization of the fullest part of the pool, as a percentage of granted capacity. |
| first_observed_epoch_seconds | Integer | When the condition was first observed, in seconds since the Unix epoch. |
| last_observed_epoch_seconds | Integer | The most recent time the condition was observed. |
| resolved_epoch_seconds | Integer | When the condition resolved, in seconds since the Unix epoch. Present only on a resolved diagnostic. |
Create Capacity Pool
Creates a new Capacity Pool with the specified provisioning. The pool is created synchronously in creating status; the backing capacity is provisioned asynchronously. Use the Describe Capacity Pool endpoint to poll until the pool's status is active.
Request
- Path: /capacity_pool/{name}
- HTTP Method: POST
Path Parameters
| Parameter name | Required? | Type | Description |
|---|---|---|---|
| name | yes | URL-safe string | The name of the Capacity Pool. |