Change History

About Versioning and Backward Compatibility

The VMS REST API versioning system ensures that any API calls existing in your code continue to work as they did previously. Operations supported by previous versions are not deprecated. Newly implemented behavior for any endpoint or parameter in a new version, if different from a previous version, is incurred only if the new version number is specified in the endpoint URL.

Specifying the version is not required for new endpoints and parameters.

Changes in VMS 5.5

The VMS REST API for VAST Cluster 5.5 includes all the changes listed in Changes in Version 8 per VAST Cluster 5.4 Release under VAST Cluster 5.4.1-5.4.4 as well as the changes detailed here.

Breaking Changes

To support larger system configurations (up to 150K views) and ensure optimal server performance, VMS version 5.5 introduces strict payload limits and enforces data pagination.

If your integration queries a large volume of objects without pagination, you will need to adjust your implementation to handle the new limits and updated response schemas.

Enforced Response Limits on /views

The non-paginated /views endpoint now strictly limits responses to a maximum of 16,000 objects.

• New Behavior: If a non-paginated request exceeds 16K objects, the server returns an error.

• Previous Behavior: Non-paginated requests could cause the server to attempt to return up to 32K objects in a single block. This caused severe performance degradation and server load.

• Action Required: For clusters with more than 16K views, you must implement pagination by appending the page and page_size query parameters to your requests.

Payload Schema Adjustments (Paginated vs. Non-Paginated)

When switching from non-paginated to paginated requests, note that the root JSON structure changes from a flat array to a paginated object wrapper containing metadata.

• Non-Paginated Response Format (Flat Array)

  Used only when total results are under 16K and no pagination parameters are passed.

   [
  {
  "id": 1,
  "path": "/",
  "alias": "/",
  "tenant_name": "default",
  "protocols": ["NFS"],
  "logical_capacity": 1169484827049,
  "physical_capacity": 27298621837,
  "created": "2026-04-28T08:10:56.289712Z"
  },
  {
  "id": 5,
  "path": "/172.27.113.12",
  "alias": "",
  "tenant_name": "default",
  "protocols": ["NFS"],
  "logical_capacity": 872306510277,
  "physical_capacity": 26219648944,
  "created": "2026-04-28T08:21:32.390299Z"
  }
  ]
  

• Paginated Response Format (Object Wrapper)

  Returned when querying using ?page=X&page_size=Y.

  {
    "count": 6,
    "next": "https://v113/api/v9/views/?page=2&page_size=2",
    "previous": null,
    "results": [
      {
        "id": 1,
        "path": "/",
        "alias": "/",
        "tenant_name": "default",
        "protocols": ["NFS"],
        "logical_capacity": 1080893568155,
        "physical_capacity": 30245250289,
        "created": "2026-04-28T08:10:56.289712Z"
      },
      {
        "id": 5,
        "path": "/172.27.113.12",
        "alias": "",
        "tenant_name": "default",
        "protocols": ["NFS"],
        "logical_capacity": 812960699069,
        "physical_capacity": 29119687922,
        "created": "2026-04-28T08:21:32.390299Z"
      }
    ]
  }
  

Object Limits on View Analytics Requests

Analytics queries targeting view-related objects are now restricted to a maximum of 50 objects per request. Previously, you could request metrics for all objects at once.

This change impacts the following endpoints:

• POST /monitors/{id}/query (with object_type=view)

• POST /monitors/ad_hoc_query?object_type=view

Action Required: If you need to retrieve analytics for more than 50 views, your application must chunk the requests by paginating over the target views first, then executing separate analytics queries for each batch of up to 50 objects.

New Endpoints

New Parameters in Existing Endpoints

Changes in Version 8 per VAST Cluster 5.4 Release

The changes listed below were introduced into the VMS REST API v8 in the major and minor release versions of VAST Cluster 5.4 up to VAST Cluster 5.4.4.

Changes in VAST Cluster 5.4.4

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.4.3

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.4.2

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.4.1

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.4.0

New Endpoints

New Properties and Parameters

Changes in Version 7 per VAST Cluster 5.3 Release

The changes listed below were introduced into the VMS REST API v7 in the various minor version releases of VAST Cluster 5.3 since VAST Cluster 5.3.0.

Changes in VAST Cluster 5.3.5

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.3.4

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.3.3

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.3.2

New Endpoints

New Properties and Parameters

Changes in VAST Cluster 5.3.1

New Endpoints

New Properties and Parameters

Changes in Version 7 (for VAST Cluster 5.3)

Authentication

This version introduces a new type of API tokens that can be used to authenticate requests to the API endpoints instead of basic authentication or authentication with JWT tokens, which are also still supported. The tokens are managed through the /apitokens/ endpoint. Usage is described in Getting Started.

The following notation is used in this guide to indicate authentication methods where required per endpoint:

• basicAuth. This refers to basic authentication using a valid VMS username and password.

• Apitokens. This refers to authentication by API tokens.

Where one of these methods is required (for almost all endpoints), authentication with JWT tokens is also supported.

API Tokens

Requesting users with the required RBAC permissions can now use the following endpoints to manage API tokens:

• /vms/{id}/set_max_api_tokens_per_user/. The PATCH operation sets the maximum number of valid tokens that a user can have.

• /apitokens/. The GET operation returns API token properties. POST creates an API token for a user.

• /apitokens/{id}/. GET returns properties of a specific API token. PATCH modifies token properties, such as token expiration.

• /apitokens/{id}/revoke. PATCH revokes a token.

Block Storage Protocol Support

You can now create a block storage subsystem by creating a view and enabling the Block protocol. To do this, specify BLOCK exclusively for the protocols property in the body parameter of PATCH and POST requests to the /views/ endpoint.

The is_default_subsystem property is now supported in the body parameter of PATCH and POST requests to the /views/ endpoint. This parameter configures a block system view to be the default subsystem for block storage volumes that are created without a view being specified in the request.

The subsystem_related property was added to the snapshot object, indicating whether the snapshot path is above, below, or matching a block subsystem.

The following endpoints were added:

• /blockhosts/. GET lists block storage hosts. POST adds block storage hosts to enable mapping to volumes.

• /blockhosts/{id}/. GET to return properties of a block host. PATCH to modify a block host. DELETE to delete a block host.

• /blockhosts/{id}/set_volumes. POST creates a mapping of a block host to volumes.

• /blockhosts/{id}/update_volumes. PATCH updates a mapping of a block host to volumes.

• /blockmappings/. GET lists mappings of block hosts to volumes.

• /blockmappings/bulk/. PATCH bulk changes mappings of hosts and volumes.

• /volumes/. GET lists block storage volumes. POST creates block storage volumes.

• /volumes/{id}/. GET returns properties of a block storage volume. PATCH modifies a volume. DELETE deletes a volume.

• /volumes/{id}/set_hosts. PATCH maps a volume to block hosts, to make the volume available to those hosts.

• /volumes/{id}/update_hosts. PATCH modifies an existing mapping of a volume to block hosts.

• /volumes/{id}/get_snapshots. GET lists snapshot IDs per volume. These can be used to map block hosts to snapshot volumes, to enable access to the snapshots.

• /volumes/{id}/fetch_capacity. GET fetches the capacity in use of a volume.

Client Metrics

A new endpoint, /tenants/{id}/client_metrics/, was added. A GET request to this endpoint lists client metrics settings per tenant. PATCH modifies client metrics settings.

Encryption with External Key Management (EKM)

The following endpoints are new:

• /tenants/{id}/deactivate_encryption_group/. On a cluster that has data encryption enabled with an external key manager, POST revokes and destroys a tenant's encryption group's keys.

• /encryptiongroups/{id}/deactivate_encryption_group/ On a cluster that has data encryption enabled with an external key manager, POST revokes and destroys an encryption group's keys.

The bypass_validation property is now supported in the body parameter of POST requests to the /clusters/{id}/set_certificates/ endpoint, to enable bypassing certificate validation.

Folder Management

• The following properties are now supported for POST requests to the /folders/create_folder/ endpoint: create_dir_mode, which sets Unix permissions mode for the new directory, and the inherit_acl boolean property, which indicates whether the directory should inherit ACLs from its parent directory. These properties are also supported for POST requests to the /quotas/ endpoint.

• A new endpoint, /folders/read_only/, supports temporarily making a folder read-only. POST makes an existing folder read-only for all users, regardless of permissions, to lock the folder temporarily from all writes. GET lists read-only folders. DELETE unlocks the read-only configuration on the folder.

  [!NOTE]
  This feature is not enabled by default and has restricted compatibility with other features.

Layer 3 Network Connectivity

You can now configure virtual IP pools and the VAST DNS service to use layer 3 connectivity, instead of the default layer 2 connectivity, by attaching a Border Gateway Protocol (BGP) configuration to the Virtual IP pool or DNS service.

The following endpoints were added:

• /clusters/bgp_table/. The GET operation lists BGP connections on the cluster.

• /bgpconfigs/. The GET operation lists BGP configurations. The POST operation creates a BGP configuration.

• /bgpconfigs/{id}/. The GET operation returns properties of a BGP configuration. PATCH modifies a BGP configuration.

You can configure a new VAST DNS service configuration to use layer 3 connectivity by passing the new enable_l3 property (to enable L3) and bgp_config_id (to specify the BGP configuration) properties in the body parameter of a POST request to the /dns/ endpoint. You can change the BGP configuration by passing the new property in the body parameter of a PATCH request to the /dns/{id}/ endpoint. Similar usage applies for a virtual IP pool with the /vippools/ endpoint.

Multi-tenancy Enhancements

• Login permission is now granted separately from role based access (RBAC) permissions.

• The new user_type property distinguishes two types of VMS manager users: cluster admins denoted by SUPER_ADMIN and tenant admins denoted by TENANT_ADMIN. Cluster admins are allowed to log into the main VMS URL for the cluster to manage the cluster. Tenant admins are allowed to log into a tenant specific VMS URL which enables them to manage a specific tenant.

• The user_type property was added to the manager object to enable the configuration of VMS users as cluster admins or tenant admins. The tenant_id property was also added to specify which tenant a tenant admin can access. To configure a tenant admin user, specify TENANT_ADMIN for user_type and use the tenant_id property to specify the tenant, in the body parameter of a POST request to the /managers/ endpoint.

• Tenants have a tenant-specific VMS URL accessible to tenant admins. A tenant specific domain name incorporated into the URL is configurable using the domain_name property of the tenant object.

• Login access for VMS manager users can now be restricted to specific IP ranges using the access_ip_ranges property. This is a property of the cluster object and the tenant object, to enable different source IPs for the cluster and for each of multiple tenants.

• On multi-tenant clusters, if you want to use a SAML identity provider (IdP) to provision manager user access, the IdP configuration must be enabled on the tenant and users must be assigned the appropriate user type through the SAML IdP to give them login permission, and tenant admins must be assigned to specific tenants through the SAML IdP. This is done as follows:

  • Enable the SAML IdP on the tenant by passing the new identity_provider_name property in the body parameter of a POST or PATCH request to the /tenants/ endpoint. (You can have multiple SAML IdPs per cluster. They are managed through the /vms/{id}/saml_config/ endpoint as previously.)

  • Use custom properties on the IdP to assign user type (user_type=TENANT_ADMIN or SUPER_ADMIN) and tenant (tenant_name) if user_type=TENANT_ADMIN to the users, in addition to the email, username and role attributes that are also defined on the provider as custom properties.

• A GET request to the new /tenants/configured_idp/ returns details of SAML IdP configuration per tenant.

• When granting VMS manager access to users on Active Directory and LDAP providers, login permissions and RBAC permissions are granted as follows:

  • The super_admin_groups property in the body parameter of a POST or PATCH request to the /ldaps/ or /activedirectory/ endpoint to configure a given LDAP or Active Directory configuration to grant cluster admin type access to any groups on the provider.

  • For tenant admin access, you can configure a single group on a provider to have tenant admin login access by specifying the group name in the tenant_admins_group_name property in a POST or PATCH request to the /tenants/ endpoint to create or update a tenant. The group name should be defined on an Active Directory or LDAP provider configured on the cluster and connected to the tenant. You can have multiple providers on the cluster, one of which of each type can be attached to any given tenant. This is controlled using the ldap_provider_id or ad_provider_id property in the body parameter in a /tenants/ request.

• You can now configure multiple local providers and enable one local provider on each tenant. A provider can be enabled on more than one tenant. The following endpoints and properties were added:

  • /localproviders/. GET lists local providers. POST creates a new local provider on the cluster.

  • /localproviders/{id}/. GET returns properties of a local provider. PATCH modifies a local provider. DELETE deletes a local provider.

  • The local_provider_id can be used in the body parameter of a POST or PATCH request to the /tenants/ endpoint to specify which local provider to enable on a tenant.

  • Local users and groups (/users/, /groups/) can now be assigned to any configured local provider, using the local_provider_id property in the body parameter in the relevant request.

  • A GET request to the new /locals3keys/ endpoint lists local provider users' access keys.

  • A POST request to the new /users/copy/ endpoint copies users with S3 keys from one local provider to another.

• The /roles/ endpoint for configuration permission roles and the /realms/ endpoint for configuring custom RBAC realms now support the tenant_id property in the body parameter, for specifying on which tenant to configure the role or realm. The realm and role objects now also have the guid property, giving each realm and role a globally unique ID.

• Capacity limits can now be set per tenant, using the capacity_rules property in the body parameter of a POST or PATCH request to the /tenants/ endpoint.

• The /users/{id}/access_keys/ endpoint, used to create S3 access keys for local provider users now supports the tenant_id property to specify for which tenant the access key pair is valid.

• A new endpoint, /users/{id}/tenant_data/, enables granting S3 permissions to users per tenant, with a PATCH request.

• The properties tenant_id and remote_tenant_guid are now supported in the body parameter of POST requests to the /protectionpolicies/ endpoint to enable creating exclusive protection policies per tenant.

• The tenant_id property is now supported by all VAST Database operations.

S3 Indestructible Object Mode

The following parameters are now supported to enable and configure indestructible object mode for S3 views, in the body parameter of PATCH and POST requests to the /views/ endpoint:

• is_indestructible_object_enabled Enables indestructible object mode.

• indestructible_object_duration. Sets the retention period for indestructible objects.

User Impersonation

The user_impersonation parameter is now supported in the body parameter of PATCH and POST requests to the /views/ endpoint. This parameter enables and configures user impersonation.

VAST Audit Log

A new endpoint, /vastauditlog/query_data/ was added. A GET request to this endpoint queries the VAST audit log.

VAST Database

A new endpoint, /vastdbtable/aggregate/ was added. A GET request to this endpoint returns historical aggregated data from VAST Database tables, suitable for displaying on a dashboard.

VAST Event Broker

The following new endpoints were added:

• /topics/. GET lists Kafka topics. POST creates Kafka topics. PATCH modifies Kafka topics.

• /topics/show/. GET returns properties of a Kafka topic.

• /topics/delete/. DELETE deletes Kafka topics.

The kafka_vip_pools property can now be used to specify a virtual IP pool to be used to access event topics exposed by the view when creating or modifying Event Broker views, in the body parameter of PATCH and POST requests to the /views/ endpoint.

Other Additions and Changes

• The access_mask_display property was added to the OpenProtocolHandle object. It exposes a readable text value for each numeric access mask.

• The hardware_type property was added to the DBox object. It shows the model, e.g., sanmina, ceres, ceres_v2.

• The monitor_action property was added to the Activedirectory and LDAP models. It enables you to configure a health check method per provider.

• The inherit_parent_mode_bits property is now supported in the body parameter of POST and PATCH requests to the /viewpolicies/ endpoint. It enables NFS behavior of inheriting POSIX settings from the parent directory versus configured values.

• The following properties are now supported in PATCH requests to the /clusters/{id}/ endpoint: enable_write_buffer_raid, force_wbr_rewrite, wb_raid_layouts.

• The drives_fw_upgrade property is now supported in PATCH requests to the /clusters/{id}/upgrade/ endpoint (upgrades firmware on SCMs and SSDs exclusively.

• The bmc_upgrade property is now supported in PATCH requests to the /clusters/run_hardware_check/ endpoint (upgrades firmware on SCMs and SSDs exclusively).

• The is_gold property is now supported in the body parameter of POST requests to the /qospolicies/ endpoint and PATCH requests to the /qospolicies/{id}/ endpoint. This boolean property can be used to grant priority QoS over views that do not have this setting enabled.

Changes in Version 6 (for VAST Cluster 5.2)

New Endpoints

The following endpoints were added to this version:

• /activedirectory/{id}/change_machine_account_password/. Changes the cluster's machine account password on a joined Active Directory domain.

• /certificates/. Enables you to manage certificates used to secure webhooks, which can be triggered by events.

  The following operations are available at this path:

  • GET. List certificates.

  • POST. Add certificates.

  To manage a specific certificate, add the certificate ID as a path parameter to form an endpoint for the certificate. The following operations are available at /certificates/{id}/:

  • GET. List details of the certificate

  • PATCH. Modify the certificate.

  • DELETE. Delete the certificate.

• /eboxes/. Enables management of EBoxes. An EBox is a VAST enclosure that contains a server and SSDs. The server runs a CNode and two DNodes in containers. The following operation is available directly on the /eboxes/ endpoint:

  • GET. Lists EBoxes in the cluster.

• /eboxes/{id}/. Add the EBox ID as a path parameter to form an endpoint for the EBox. The following operations are available for a specific EBox:

  • GET. Lists details of the EBox.

  • PATCH. Modifies the EBox.

  • DELETE. Deletes the EBox.

• /eboxes/{id}/control_led/. A PATCH operation toggles the LED state.

• /eboxes/add/. A POST operation on this endpoint adds an EBox to the cluster.

• /encryptedpaths/. If EKM encryption is enabled on the cluster, this endpoint enables the management of paths that are encrypted with their own dedicated encryption groups and keys, which are subgroups of the parent tenants. The following operations are available:

  • GET. Lists encrypted paths.

  • POST. Creates an encrypted path. The path must not already exist. Create a view to enable access to the path only after creating the encrypted path.

• /encryptedpaths/{id}/ The following operations are available:

  • GET. Lists details of the encrypted path.

  • PATCH. Modifies an encrypted path.

  • DELETE. Deletes an encrypted path.

• /encryptiongroups/{id}/revoke_encryption_group/. Now that encryption groups can belong to encrypted paths as well as to tenants, this endpoint can be used to revoke the encryption key for any encryption group.

• /encryptiongroups/{id}/reinstate_encryption_group/. Now that encryption groups can belong to encrypted paths as well as to tenants, this endpoint can be used to reinstate a revoked encryption key for any encryption group.

• /encryptiongroups/{id}/rotate_encryption_group_key/. Now that encryption groups can belong to encrypted paths as well as to tenants, this endpoint can be used to revoke the key for any encryption group.

• /kafkabrokers/ This endpoint enables you to manage external Apache Kafka Broker configurations, which are now supported for event publishing. The following operations are available directly on this endpoint:

  • GET. Lists Kafka broker configurations.

  • POST. Adds a configuration for an external Kafka broker.

• /kafkabrokers/{id}/. The following operations are available on this endpoint:

  • GET. Lists details of a specified Kafka broker configuration.

  • PATCH. Modifies a Kafka broker configuration

  • DELETE. Deletes a Kafka broker configuration.

• /kafkabrokers/{id}/list_topics A GET request to this endpoint retrieves Kafka topics for a specific broker.

• /nvrams/{id}/control_led/ . A PATCH request to this endpoint turns an NVRAM LED on and off.

• /protectedpaths/{id}/modify_member/ A PATCH request to this endpoint changes a protected path stream to sync replication from async replication or vice versa.

• /protectedpaths/{id}/prefetch_folder. This endpoint supports the prefetching of data to the cache in a global access path. The following operations are available:

  • GET. Lists prefetch tasks.

  • POST. Creates a prefetch task, specifying a folder under a global access path on a remote source peer.

  • DELETE. Deletes a prefetch task from the records and can abort a task in progress if requested.

• /racks/. The racks endpoint enables you to manage racks, which are an administrative resource that you can use to reflect physical rack and stack layout in the data center. Racks can be defined at the installation and expansion stages and manually during cluster operation. CBoxes, DBoxes, and EBoxes can be assigned to racks. Racks can be named and described. Unit positions in the rack can be assigned to boxes.

  The following operations are available:

  • GET. Lists racks.

  • POST. Adds a new rack.

• /racks/{id}/ for managing a specific rack.

  The following operations are available:

  • GET. Retrieve details of a rack.

  • DELETE. Delete a rack.

  • PATCH. Modify a rack.

• /racks/{id}/rename/. A PATCH request against this endpoint renames a rack.

• /racks/{id}/add_boxes/. A POST request to this endpoint assigns boxes to a rack.

• /ssds/{id}/control_led/. A PATCH request to this endpoint turns an SSD LED on or off.

• /tables/load_from_file/. A POST request to this endpoint creates a database table from a Parquet or CSV file.

• /tenants/{id}/client_ip_ranges/. A PATCH request against this endpoint adds or removes one or more client IP ranges for a tenant.

• /virtual-machines/ . This endpoint represents hosts that run CNodes and/or DNodes as containers. These include EBox hosts (which each comprise one CNode container and two DNode containers) and virtual machines comprised by VAST on Cloud (VoC) clusters on GCP infrastructure, each of which also comprises one CNode container and two DNode containers. The endpoint supports the GET operation, which lists all such hosts and their details.

• /virtual-machines/{id}/. This endpoint represents a specific host that runs CNodes and DNodes in containers. It supports the GET operation, which returns details of one specific such host.

• /webhooks/. The configuration of webhooks to be triggered by events was moved into this dedicated endpoint. It is now possible to configure multiple webhooks per event. Webhooks can also be secured by certificates (see also /certificates/). Certificates used to secure webhooks are manageable by a dedicated endpoint.

  The following operations are available directly on this endpoint:

  • GET. Lists webhooks.

  • POST. Configures a new webhook.

• /webhooks/{id}/ for managing a specific webhook.

  The following operations are available:

  • GET. Retrieves details of a specific webhook.

  • PATCH. Modifies a webhook.

  • DELETE. Deletes a webhook.

Other Additions and Changes

• You can now use the alt_s3_host_port parameter with the /callhomeconfigs/{id}/ PATCH endpoint to specify an alternative S3 service host for uploading callhome bundles.

• Multiple webhooks can now be associated with an event definition. To do this, pass the webhooks parameter with an array of webhook IDs with a PATCH request on the /eventdefinitions/{id}/ endpoint.

• The following parameters were previously supported by PATCH operations on the /eventdefinitions/{id}/ and /eventdefinitionconfigs/{id}/ endpoints to configure a single webhook. They are now configurable as part of the definition of each webhook using the new /webhooks/ endpoint: webhook_url, webhook_method, webhook_data, webhook_params, webhook_headers.

• The bmc_upgrade property was added to the body parameter of the following endpoints:

  • /clusters/ POST

  • /clusters/{id}/upgrade/ PATCH

  • /clusters/{id}/upgrade_without_file/ POST

  VMS upgrades BMC and all relevant components only if the upgrade request was submitted with this flag enabled.

• The rack_id query parameter can now be passed in a GET request on the /cboxes/ and /dboxes/ endpoints to filter boxes by rack.

• The require_smb_signing boolean flag was added to the Tenants object and can be passed with POST and PATCH requests on the /tenants/ endpoint to enable or disable the requirement of SMB signing.

• Sync replication can now be configured with POST and PATCH requests on the /protectedpaths/ endpoint. To configure a sync replication protected path or to change a protected path from async to sync replication:

  • Set capabilities to SYNC_REPLICATION in a POST or PATCH request on the endpoint.

  • Use the sync_disconnect_time parameter to specify the period of time, in seconds, without communication between sync replication peers, after which the peers are disconnected.

• On the /users/non_local_keys/ endpoint, the username and login_name parameters now enable you to query non-local provider users by their username or login name when generating an S3 access key pair for the user.