API

The VCF Operations API uses different payloads for finding, canceling, and deleting alerts. Treating those operations as interchangeable can either fail validation or broaden a cleanup beyond the alerts you intended to remove. This follow-up corrects the API section in Bulk Delete Alerts in VCF Operations. The safe sequence is: Query candidate alerts without changing them. Review every returned alert ID and account for pagination. Cancel only the approved IDs with a uuid-values body. Verify those IDs are now CANCELED. Delete the same IDs with a direct AlertQuery body. Query again to confirm that they are gone. Before You Begin Fix or tune the alert definition first. Deleting alert history does not stop the condition from generating new alerts. Use a VCF Operations account whose application role and object scope permit the required alert operations. Take any database backup required by your change policy before a large cleanup. Start with one small batch. The API documents a default query page size of 1,000, so a single response is not proof that you found every match. Use a trusted certificate. The examples intentionally do not bypass TLS verification. Set the appliance name, create a private working directory, and read an existing session token without placing it in shell history. Store the authorization header in a mode-600 file so the token is not expanded into each curl process argument, then remove it as soon as the cleanup is verified: ...

While putting together the VCF Automation 9.1 API getting started post, I spent some time in the in-product API Help Center. Log into the VM Apps tenant, click your username, API Help Center > Explore Automation APIs. The Swagger pages render fine, but the moment you try an actual call, it fails. The Servers box for the VCF Automation (Blueprint) API shows: http://localhost:8600 Swagger UI builds Try It Out requests from servers[0].url, so the browser dutifully sends every request to port 8600 on your own workstation. Connection refused, every time. The documentation is correct; the advertised host is not. ...

Back in 2022 I wrote vRA 8 API getting started, two curl calls and you had a bearer token. Since then the product has been renamed twice (vRealize Automation → VMware Aria Automation → VCF Automation) and, more importantly for anyone with scripts in production, the authentication flow changed in VCF 9.x. Neither of the two calls from that post works against a 9.1 appliance. This is the 9.1 version of the same post: the minimum you need to do before you can actually query the API, with curl. ...

Continuing the credential cleanup in the same 9.1 environment from the expired password sync and VCFOPSPWID03 posts, one credential refused to settle: the service account SDDC Manager uses to talk to the NSX Manager API, svc-sddcmanager-a-nsx-mgmt--8199 in my lab. It showed up as disconnected, every remediation attempt failed, and the environment kept trying to rotate it in a loop. This one took several wrong turns before the actual root cause surfaced, and almost every wrong turn taught me something worth writing down. The short version: ...

While rotating credentials in the same 9.1 environment I covered in the expired password sync post, an Update of the NSX Manager admin password (credential type API) from VCF Operations kept failing after about a minute with error code VCFOPSPWID03 and a spectacularly unhelpful message: “call from NSX received invalid response.” The actual cause turned out to be simple, NSX rejected the new password because it had already been used on that manager. This being a lab, I was deliberately recycling a previous password. That goes against best practices, and NSX enforces it. But the way the error surfaces (and the way the reuse policy behaves in this build) is worth writing down. ...

In VCF 9.1, Fleet Password Management accounts can get stuck in EXPIRED status, and the password workflows changed compared to 9.0. In 9.0, you may have seen UI actions such as Disconnected or Remediate. In the 9.1 environment I was working on, those actions were not available. The UI exposed Update, and the Fleet Password Management API provides the same kind of workflow: query password accounts, then update or rotate the password. ...

If you need to pull log events programmatically from VMware Aria Operations for Logs (formerly vRealize Log Insight), filtering by a specific hostname, this guide walks you through the entire process, from authentication to querying the powerful internal API endpoint. This approach is inspired by Brock Peterson’s excellent series on the Aria Operations for Logs API, expanded here with full session authentication steps and hostname-specific query examples. Prerequisites Before we begin, you’ll need: ...

API correction (August 25, 2026): The UI workflow below remains useful, but the API request bodies originally published in this article were incorrect. Use the reviewed follow-up, Safely Canceling and Deleting Alerts with the VCF Operations API, for the supported query, cancel, and targeted-delete sequence. If you manage a VMware Aria Operations (formerly vROps) environment, you know how quickly alert fatigue can set in. In this guide I will focus specifically on the “Guest OS Experiencing CPU queue” alert. While helpful in identifying CPU-constrained VMs, it can quickly generate thousands of entries if you have a heavily over provisioned environment. ...

In the world of modern infrastructure operations, observability is only as good as the actions it drives. Integrating VMware Cloud Foundation (VCF) Operations (formerly Aria Operations) with ITSM platforms like ServiceNow is a critical step for many of my clients. It transforms passive monitoring into active incident management. However, as with any integration involving webhooks and external APIs, things don’t always go according to plan. Recently, while implementing a ServiceNow integration following standard deployment guides (kudos to Brock Peterson for his excellent documentation on ServiceNow Management Packs and Webhooks), I hit a roadblock. My instance was failing to send notifications, and the standard UI errors were vague. ...

Repeated ApiGwServicePrincipal expired-token warnings in apigw.log are a known vCenter Server 8.0 issue. Broadcom identifies a possible Security Token Service (STS) condition that causes an endless loop in the vsphere-ui service. The permanent resolution is to upgrade to vCenter Server 8.0 Update 3e or a later supported release. An earlier version of this article recommended changing the rsyslog imfile severity assigned to apigw.log. That does not stop the messages, reduce how often vCenter writes them, or correct the STS/UI loop. The procedure has been removed. ...