Security Services Platform API Operations Index
All available Security Services Platform API Operations
Retrieves a list of alarm definitions based on specified filter criteria. This endpoint supports filtering by feature names, severities, event types, and enabled status. The response includes detailed information about each matching alarm definition.
Retrieves a single alarm definition using its unique identifier. Returns detailed configuration information about the alarm definition including its feature name, event type, severity, and other associated metadata.
Update Alarm Definition
Get alarm instances based on filter criteria
Update the states of a list of alarm instances by IDs
Retrieves a single alarm instance using its unique identifier
When invoking this API, the Alarm instances are accounted for in a map where the key is a category, by default feature name, and the value contains counts by severity. When the optional FeatureName request parameter is specified, the resulting list will only include the feature names passed along with the instance counts by severity for those features.
Returns saved remote backup server (SFTP) settings used by Backup and Restore. 204 if none configured.
Saves remote backup server settings; include current _revision from GET when updating.
Returns scheduled (recurring) backup policy. 204 if not configured.
Saves scheduled backup policy; set weekly or interval fields to match backup_schedule_type.
Starts an on-demand backup; poll GET /backup/status/{id} using the id from the 202 response.
Returns one backup job by id (from POST /backup or GET /backup/status).
Returns the backup status history. Results are always returned in chronologically reverse order, i.e., the latest backup status first. To get the latest backup status, set the page size to 1 without other query parameter. If there's no latest backup, then the call returns an empty list.
Starts restore from backup_id; poll GET /restore/status/{id} using the id from the 202 response.
Returns one restore job by id (from POST /restore or GET /restore/status).
Returns all restore status history. Results are always returned in chronologically reverse order, i.e., the latest restore status first.
Retrieves the current status of an active or recently completed certificate rotation workflow, including overall progress and per-vertical summary node counts.
When to use:
Use this endpoint to get a high-level view of the certificate rotation. It returns the
overall_status, progress_percent, and per-vertical summary counts
(success/failed/pending nodes) for all participating platform components.
Notes:
- This endpoint returns summary-level data only - node-level detail arrays
(
success_nodes,failed_nodes,pending_nodes) are empty. To retrieve node-level details for specific verticals or statuses, usePOST /trust/trust-rollout-statuswith filter criteria. - When no rotation is active (or after calling
DELETE), the response body will reflect an empty/reset state. - This endpoint is safe to poll during an active rotation. The
progress_percentfield is updated continuously and represents an approximate progress indicator. - The
vertical_keyvalues in thevertical_statusarray are the valid inputs for thevertical_namesfilter inPOST /trust/trust-rollout-status.
Retrieves the certificate rotation status with node-level detail for specific verticals and/or node statuses. This is the primary endpoint for diagnosing rotation failures.
When to use:
Use this endpoint after GET /trust/trust-rollout-status reveals that a rotation has
COMPLETED_WITH_FAILURES or is still IN_ROTATION with pending nodes. Filter by
vertical and status to retrieve the exact list of nodes (with error messages) that
require attention.
Filter Behavior:
vertical_names: Restricts results to the specified verticals. Values must match theTrustRolloutStatusVerticalKeyenum. Obtain valid values fromvertical_keyfields inGET /trust/trust-rollout-status.include_status: Restricts node-level detail to nodes in the specified states (SUCCESS,FAILED,PENDING). Only matching nodes are populated insuccess_nodes,failed_nodes, orpending_nodes.- If the request body is omitted, the response is equivalent to
GET /trust/trust-rollout-status(summary-level data, no node detail).
Important: Node-level detail is only available for certain verticals (e.g.,
BAREMETALSECURITY, SENSOR). Other verticals (NSX, AVI, SSP, LH) always
return empty node arrays - their status is limited to START_SUCCESSFUL or
FAILED_TO_START_ROTATION.
Chaining:
- Call
GET /trust/trust-rollout-statusto identify the overall status and which verticals havefailed_node_count > 0in theirstatus_summary. - Call this endpoint with those vertical keys and
include_status: ["FAILED"]to retrieve node-level error details for remediation.
Notes:
- Returns
400ifvertical_namescontains values not in theTrustRolloutStatusVerticalKeyenum, or ifinclude_statuscontains values outside ofSUCCESS,FAILED,PENDING. - Verticals not matching the filter are excluded entirely from the response.
Clears and permanently resets the certificate rotation rollout status, returning the system to an idle state. This corresponds to the "Clear Status" action in the SSP Trust Management UI.
When to use:
Call this endpoint after the rotation workflow has reached a terminal overall_status
(COMPLETED_SUCCESSFULLY or COMPLETED_WITH_FAILURES) and you have acknowledged the
result. This resets the system so a new rotation can be tracked cleanly in the future.
Preconditions:
- The workflow must NOT be actively running. If
overall_statusisIN_ROTATION, this call returns400. Verify the current state withGET /trust/trust-rollout-statusbefore calling this endpoint.
Side Effects:
- All rollout status data is permanently deleted. Subsequent
GET /trust/trust-rollout-statuscalls will return an empty/reset status object. - This does NOT reverse or undo any certificate changes made during the rotation.
- This action is irreversible - cleared status cannot be recovered.
Retrieve hierarchical health status: Features -> Services -> Components.
Structure:
- Features are high-level groupings (e.g., "intelligence", "analytics")
- Services are feature components (e.g., "cluster-api")
- Components are pods/deployments
Key points:
- Overall platform status:
UP,PARTIALLY_UP,DOWN - Aggregated from feature status
- See API guide for when to use this vs other endpoints
Retrieve complete cluster status: health, config, form factor, versions.
Returns:
- Health metrics: CPU, memory, storage (1/5/15 min averages)
- Config: cluster ID, name, node count, K8s version
- Network metrics: transmit/receive rates
- Form factor: current and desired, including transitions
- Versions: product_version
Form factor transitions track scaling:
NOT_STARTED,IN_PROGRESS,COMPLETED,FAILED- Check
messageandjob_namefor details
See API guide for endpoint comparison and workflow.
Retrieve service health and resource metrics per category.
Service Categories: MESSAGING (message broker), ANALYTICS (analysis), DATA_STORAGE (storage), CONFIGURATION_DATABASE, PLATFORM_SERVICES, METRICS, BARE_METAL_SECURITY, AI_ASSISTANT_PLATFORM, AI_ASSISTANT_THREAT_DEFENSE
Per-service metrics:
health: UP, PARTIALLY_UP, DOWN (60-second cache)cpu: [1min, 5min, 15min] averages in coresmemory,storage: current usage in GBallocated_*: total available resources
Messaging service metrics:
byte_in_rate,byte_out_rate: Bytes/secrequest_rate: Messages produced/sec
List all licenses.
Get Cloud Connector Configuration
Update Cloud Connector Configuration
Get Cloud Connector Configuration Status
Get Available Cloud Connector Regions
Submit a deployment action for a platform feature
Retrieve staged deployment settings for a feature.
Read live deployment and pre-check status for a platform feature
Get Security Intelligence Configurations
Update Security Intelligence Deployment Configuration
Get Security Intelligence Configurations Status
Get Malware Analysis VC Configuration
Update Malware Analysis VC Configuration
Get Malware Analysis VC Configuration Status
Update the global configuration for the security content service. This includes the connectivity mode setting which controls connectivity to cloud services. The _revision field is required in the request payload. Obtain the current _revision by issuing a GET request first. If the provided _revision does not match the current revision, the request will be rejected with a 409 Conflict error. Note: If connectivity_mode_changeable is false, any attempt to modify the connectivity_mode field will be rejected with a 409 Conflict error. Check the connectivity_mode_changeable field in the GET response before attempting to update.
Get the global configuration for the security content service. This includes the connectivity mode setting which controls connectivity to cloud services. The response includes the connectivity_mode_changeable field which indicates whether the connectivity mode can be modified. When false, the connectivity mode cannot be changed.
Get the IDPS signature configuration for a specific site. Returns the assigned version and auto-update settings for the site.
Update IDPS signature configuration for a specific site. The configuration must already exist. Use POST to create a new configuration. The _revision field is required in the request payload. Obtain the current _revision by issuing a GET request first. If the provided _revision does not match the current revision, the request will be rejected with a 409 Conflict error.
Create IDPS signature configuration for a specific site.
Delete the IDPS signature configuration for a specific site.
Get the list of versions available for the feature types passed in feature_type query parameter. Currently supported feature types are GEO_IP, IDPS_SIGNATURE, IP_REPUTATION, URL_DB.
Returns the feature download info for the feature type and feature version if exists else response with 404 response code will returned. To get the latest version, pass LATEST for feature_version query parameter for the feature type.
If SSP is in disconnected mode (see field CLOUD_CONNECTIVITY_MODE in SecurityContentConfig) then the response depends on configurations - automatic update and feature version mapping. When automatic update configuration takes precedence over feature version mapping and returns latest feature version. Latest version will be returned when both automatic update and feature version mapping is not set. When automatic update is disabled and feature version mapping is set, then the download info for the mapped version will be returned.
Latest version is determined based on the feature_updated_at timestamp. When VTIS provides an update timestamp for the feature, that is used as the authoritative sort key. When VTIS does not provide an update timestamp, the SSP processing time (when the feature was ingested) is used as a fallback. The feature version with the most recent feature_updated_at is returned as LATEST.
Upload a security content mega bundle archive file to security content store. After successful upload, a upload ID will be generated and returned. The status of the upload can be fetched using the ID. After the mega bundle is uploaded, the included features will be available through content APIs.
List of mega bundles. Optionally filter by bundle type.
Get the mega bundle metadata.
Delete the mega bundle.
Get the current processing status of an uploaded mega bundle. This endpoint provides information about upload status.
Retrieves all sites currently connected to the platform. By default, all site types (NSX_MANAGER, SSP and AVI) are returned, but query parameters can be used to filter the sites.
Notes:
- If no sites are connected to the platform an empty list will be returned.
- The platform does not store the username and password that were used to onboard the site, so these fields will always be returned empty.
This onboarding workflow includes initiating a connection to the site, running prechecks and onboarding the site. These actions are performed asynchronously. The state of the site can be checked by calling GET on the status_url returned in the response. Onboarding is completed when the current_state of the site is READY.
The desired_state property in the body of this request allows you control the workflow more granularly. Providing a desired_state of PREPARE will run the prechecks and then halt, preventing the site from actually being onboarded to the platform. Providing a desired_state of ONBOARD will run the prechecks, and if they pass, will start onboarding the site to the platform.
Once a site has been onboarded, use PUT /sites/{site-id} to take any needed actions, like reconnecting the site if it becomes disconnected.
Notes:
- The credentials provided are one-time use to establish a connection. They are never stored or re-used.
Retrieves a specific site onboarded to the platform by the site id provided. If the site does not exist on the platform, a 404 will be returned.
Notes:
- The platform does not store the username and password that were used to onboard the site, so these fields will always be returned empty.
Update an existing site to support actions like reconnecting. The platform will keep the site up to date as long as the site remains connected and healthy, thus, updating information on the site is not required. However, in the case of a connection being lost, update allows the site to be reconnected using provided credentials.
Notes:
- The credentials provided are one-time use to re-establish the connection. They are never stored or re-used.
- Connection Type Changes Not Allowed: You cannot change the connection type (DYNAMIC <-> STATIC) during a reconnect operation. The connection type must remain the same as it was during initial onboarding.
- To Change Connection Type: You must first offboard the site, then onboard it again with the new connection type.
- IP/Hostname Changes Allowed:
- For DYNAMIC mode: You can change the hostname during reconnect.
- For STATIC mode: You can change the host addresses (IPs/ports) during reconnect.
Deleting a site will asynchronously perform actions to remove references to this SSP instance on the site and, when finished successfully, delete the site from the platform.
If the connection between the site and the platform is not healthy, then the force parameter can be used. When force is true, the platform will attempt best-effort to remove references to this SSP instance from the site, but will ignore errors from the site. The result will be the removal of the site from the platform, but possibly references to the platform remaining on the site. This scenario can lead to errors when attempting to onboard the site to a new SSP. In this scenario, the force parameter will have to be used when onboarding the site.
During offboarding, the site enterprise admin username and password are required to allow SSP to delete certain artifacts that are specific to this platform.
Notes:
- The credentials provided are one-time use and never stored or re-used.
- The status of offboarding can be checked by calling GET /sites/{site-id}. Once offboarding is completed, the site will automatically be deleted, at which point calling GET /sites/{site-id} will return a 404. This signifies a successful offboard and deletion.
Retrieve the site settings for SSP features for a specific site. The settings here DO NOT show whether a feature is activate or inactive on the platform, they only reflect the configured feature settings for each feature for the specified site. There is no need to create these feature settings, they are created as part of the onboarding workflow for the site.
Notes:
- Although all site feature settings are returned, not all of the settings are editable via API.
Update the site settings for activated SSP features for a specific site. These settings are created and configured during the onboarding workflow. Configuring settings here DOES NOT control the deployment or undeployment of the feature on the platform, it only configures the feature settings for a feature for this specific site.
Notes:
- Although all site feature settings are returned, not all of the settings are editable via API.
Get telemetry config information.
Updated telemetry config information.
This API exports all the aggregated telemetries in the specified format.
Retrieves the deployment configuration metadata for the Upgrade Coordinator. This includes the target version, revision number, the user who initiated the deployment, and the creation timestamp.
Modifies the deployment configuration for the Upgrade Coordinator. Use this operation to update specific deployment parameters, such as the target upgrade version and the configuration revision.
Retrieves the comprehensive configuration status of the Upgrade Coordinator. This includes deployment configuration details (such as status, revision, the user who initiated the deployment, and the creation timestamp), alongside execution metrics including the overall status, precheck results, and current progress.
Retrieves the list of all available pre-checks and upgrade step definitions. This endpoint provides visibility into the upgrade workflow phases and pre-checks validations that will be executed, enabling the UI to display the upgrade process to the user before execution.
The steps are listed in the order they will be executed during the upgrade process. This endpoint returns step definitions only, not execution status. To retrieve execution status and progress, use GET /upgrade/status.
Executes the SSP upgrade operation asynchronously based on the specified action. Returns immediately with a status URL; use GET /upgrade/status to monitor progress.
Supported actions:
PRECHECKS_ONLY: Runs only pre-upgrade validation checks without performing the upgrade. This operation is idempotent and non-disruptive; it can be safely run on a live production system to assess readiness before a maintenance window. PRECHECKS_ONLY is only allowed when the upgrade status is NOT_STARTED. Only one pre-checks operation can run at a time.
START: Runs pre-checks followed by the full upgrade. This is the standard upgrade flow. START is only allowed when the upgrade status is NOT_STARTED. Requires a scheduled maintenance window as the system may experience downtime during the upgrade. Ensure a backup is taken before initiating. Do not interrupt the upgrade process once initiated.
CONTINUE: Starts the upgrade without running pre-checks. CONTINUE is only allowed when the upgrade status is NOT_STARTED and pre-checks have completed successfully, returns an error for any other state.
RETRY: Resumes the upgrade workflow from the failed step. Already completed upgrade steps are skipped automatically. RETRY is only allowed when the upgrade status is FAILED, which means pre-checks have already passed. If pre-checks failed, use START again.
Recommended workflow:
- Deploy the upgrade coordinator via the LCM feature deploy API (PUT /lcm/features/UPGRADE_COORDINATOR with action DEPLOY).
- Check available versions (GET /upgrade/available-versions).
- Run pre-checks (POST /upgrade?action=PRECHECKS_ONLY) and review results (GET /upgrade/status).
- During a maintenance window, start the upgrade (POST /upgrade?action=START or POST /upgrade?action=CONTINUE if pre-checks already passed), and monitor progress (GET /upgrade/status).
- If upgrade fails, address the issue and retry (POST /upgrade?action=RETRY).
- Review upgrade history (GET /upgrade/history) after completion.
- Undeploy the upgrade coordinator via the LCM feature undeploy API (PUT /lcm/features/UPGRADE_COORDINATOR with action UNDEPLOY).
Retrieves real-time status and detailed progress information for the upgrade operation. This endpoint provides visibility into upgrade execution with granular reporting for each upgrade phase.
Poll this endpoint at regular intervals while upgrade is in progress.
Upon completion, verify that overall_status is SUCCESS before proceeding with the LCM feature undeploy API to uninstall the upgrade coordinator. If status is FAILED, examine the steps array for the failed step to identify root cause or connect with VMware Support for assistance.
If no upgrade has been initiated, the response indicates NOT_STARTED status.
Returns the currently deployed SSP version and the list of versions available for upgrade. The versions_for_upgrade list is sorted in descending order with the latest version first and contains only versions strictly greater than the currently deployed version. The list may be empty if no newer versions are available.
This API is served directly by the cluster-api service and is accessible even when upgrade-service is not running.
Returns the complete list of SSP upgrade attempts. Each entry records an upgrade attempt with its versions, status, and timing metadata. Returns an empty list if no upgrades have been attempted (e.g. fresh deployments).
This API is served directly by the cluster-api service and is accessible even when upgrade-service is not running.