Manage Momento Roles
Momento provides a CLI and an HTTP API for managing the roles on your account. A role is a named set of permissions that you assign to account members and API keys to control what they can do.
This page contains brief explanations of necessary terms. See roles and permissions to learn more about concepts related to authentication, including permission sets, roles, and how credentials bind permissions.
There are two kinds of role:
- System roles are the built-in roles Momento provides (such as Owner, Operator, and Viewer). They cannot be modified or deleted.
- Custom roles are roles you define, with a fine-grained permission set that you control. This API lets you create, update, list, and delete custom roles.
This is a global, account-level API served from a single endpoint: https://mga.registry.prod.a.momentohq.com.
Unlike the region-based cache endpoints, it is not tied to a specific cell or region.
Authentication
You will need a v2 Momento API Key that grants auth-management access on your account. API Keys control access to Momento services and can be set to expire.
Our Momento roles API (and roles CLI) does not accept disposable tokens or legacy API Keys.
- Momento CLI
- HTTP API
The CLI will use your default profile (created via momento configure), or you can specify a --profile.
The API Key must be provided in the Authorization header.
Error responses
All errors share a common JSON body:
{
"code": "Bad Request",
"message": "A human-readable description of what went wrong."
}
| Field | Type | Description |
|---|---|---|
| code | String | A short, machine-readable label for the error class (for example, Bad Request, NotFound, PermissionDenied). |
| message | String | A human-readable description of the error. |
| err | String | An optional additional error metadata string, present only for some errors. |
The CLI formats these errors in plaintext for you.
Role object
Every role is represented by the same JSON shape:
{
"role_id": "r-12345",
"role_name": "analytics-readonly-role",
"role_type": "custom",
"description": "Read-only access for the analytics team",
"permissions": {
"rules": [
{
"type": "cache",
"permissions": ["read", "list"],
"caches": "*",
"items": "*"
}
]
}
}
| Field | Type | Description |
|---|---|---|
| role_id | String | The unique identifier for the role. Use this value to update or delete a custom role, or to assign the role to an API key. |
| role_name | String | The human-readable name of the role. |
| role_type | String | Either system (built-in) or custom (user-defined). |
| description | String | An optional description of the role. Omitted when the role has no description. |
| permissions | Object | The role's permission set. See Permission set. |
The CLI formats the role object in plaintext for you.
Permission set
A permission set describes exactly what a role is allowed to do. It is a list of rules, plus optional conditions that constrain when the permissions apply:
{
"rules": [ /* one or more rule objects */ ],
"conditions": [ /* zero or more condition objects */ ]
}
| Field | Required? | Type | Description |
|---|---|---|---|
| rules | yes | Array | The permission rules that make up the role. See Rules. |
| conditions | no | Array | Additional constraints that apply to the whole permission set. See Conditions. Defaults to an empty list. |
Rules
Each rule is an object tagged by a type field. The other fields depend on the type. Every rule carries a permissions array; the valid permission values depend on the rule type.
Rule type | Valid permissions | Other fields |
|---|---|---|
account_management | read, list | — |
auth_management | read, write, list | items (must be "*") |
resource_management | read, write, list | resources (must be "*") |
database | read, write | databases, items |
cache | read, write, list | caches, items |
topic | read, write, list | caches, topics |
store | read, write, list | stores, items |
function | invoke | caches, functions |
Selectors
The databases, caches, stores, topics, functions, and items fields are selectors. A selector is either the wildcard string "*" (meaning "all"), or an object that names a specific resource:
| Selector | Wildcard | Object forms | Used by |
|---|---|---|---|
| Name | "*" | { "name": "my-cache" } | databases, caches, stores |
| Name or prefix | "*" | { "name": "my-topic" } or { "prefix": "room-" } | topics, functions |
| Item | "*" | { "key": "my-key" } or { "key_prefix": "public/" } | database/cache/store items |
The items field on an auth_management rule and the resources field on a resource_management rule must always be the wildcard "*".
A Database rule's permissions array contains "read", "write", or both.
Rule examples
Full access to all caches and their items:
{ "type": "cache", "permissions": ["read", "write", "list"], "caches": "*", "items": "*" }
Read-only access to keys under a prefix in a single cache:
{
"type": "cache",
"permissions": ["read"],
"caches": { "name": "prod-cache" },
"items": { "key_prefix": "public/" }
}
Read and write access to all Momento Cache Databases and their items:
{
"type": "database",
"permissions": ["read", "write"],
"databases": "*",
"items": "*"
}
Read-only access to all keys under a prefix in a single named Database:
{
"type": "database",
"permissions": ["read"],
"databases": { "name": "orders" },
"items": { "key_prefix": "orders:2026-" }
}
Publish to all topics whose name starts with room- in one cache:
{
"type": "topic",
"permissions": ["write"],
"caches": { "name": "chat-app" },
"topics": { "prefix": "room-" }
}
Invoke a single function:
{
"type": "function",
"permissions": ["invoke"],
"caches": { "name": "edge-app" },
"functions": { "name": "resize-image" }
}
Conditions
Conditions constrain when the permission set applies. Currently the only supported condition is an ip_filter, which restricts requests to a set of allowed CIDR ranges (IPv4 or IPv6):
{
"ip_filter": {
"allowed_cidr_ranges": ["10.0.0.0/8", "192.168.1.0/24", "2001:db8::/32"]
}
}
| Field | Type | Description |
|---|---|---|
| ip_filter.allowed_cidr_ranges | Array<String> | The CIDR ranges from which requests are allowed. Each entry must be a valid CIDR range, including a prefix length (for example, 10.0.0.0/8, not 10.0.0.1). |