VMware Workstation is mostly a desktop tool, but it still exposes enough automation surface to make lab work less manual. The local vmrest service can list virtual machines, inspect details, and perform common power operations without opening the GUI.

This is not vCenter. The API is intentionally smaller, and it is best suited to local lab automation rather than full lifecycle management. If you need to create complete environments from scratch, you may still end up combining the REST API with vmrun, copied VM templates, or a different platform entirely.

The current API reference lives under Broadcom’s developer docs:

VMware Workstation Pro API

Configure vmrest credentials

From the VMware Workstation installation directory, configure credentials for the REST API:

cd "C:\Program Files (x86)\VMware\VMware Workstation"
.\vmrest.exe -C

Example output:

VMware Workstation REST API
Copyright (C) 2018-2019 VMware Inc.
All Rights Reserved

vmrest 1.2.0 build-14665864

Username:chadduffey

New password:
Retype new password:

Processing...
Credential updated successfully

Then start the service:

.\vmrest.exe

By default it serves the API locally:

Serving HTTP on 127.0.0.1:8697

That local binding is a good thing. This service controls local virtual machines, so do not casually expose it to the network.

Use the API explorer

Open the local vmrest URL in a browser to view the API explorer. The explorer is useful because it shows the available endpoints and lets you test requests interactively.

Use the Authorize button and provide the username and password you configured with -C. The sample requests will then include the required Authorization header.

The API uses Basic authentication. If you are scripting against the default local HTTP endpoint, remember that the risk model assumes local access. If you change binding or routing in future versions, treat that credential like any other administrative credential.

Calling it from PowerShell

Create the Basic auth header:

$username = "chadduffey"
$password = Read-Host -AsSecureString "vmrest password"
$plainPassword = [Runtime.InteropServices.Marshal]::PtrToStringAuto(
    [Runtime.InteropServices.Marshal]::SecureStringToBSTR($password)
)

$basic = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$username`:$plainPassword"))

$headers = @{
    Accept = "application/vnd.vmware.vmw.rest-v1+json"
    Authorization = "Basic $basic"
}

List registered VMs:

Invoke-RestMethod -Uri "http://127.0.0.1:8697/api/vms" -Headers $headers

Example output:

id                               path
--                               ----
F7G7IGFGK9KDT7UD72J24EL9AN9NPPPF D:\Ubuntu-Dev\Ubuntu Dev.vmx
KR5VJF8603O2NP18J8TNIGN0V8TKNOH9 D:\Win2k3-2\Win2k3-2.vmx
T5E8QNC0QPF842N8CAH8IPMF78VCNMDJ D:\client1\Client1.vmx

From there, you can use the returned VM IDs for follow-up operations.

A small lab helper

For lab work, the most useful automation is often “show me what is registered and let me power on a specific machine.”

$baseUri = "http://127.0.0.1:8697/api"

$vms = Invoke-RestMethod -Uri "$baseUri/vms" -Headers $headers
$vms | Format-Table id, path

$target = $vms | Where-Object { $_.path -like "*Windows Server 2019*" } | Select-Object -First 1

if ($null -eq $target) {
    throw "Could not find the requested VM"
}

Invoke-RestMethod `
    -Uri "$baseUri/vms/$($target.id)/power" `
    -Method Put `
    -Headers $headers `
    -Body (@{ power_state = "poweredOn" } | ConvertTo-Json) `
    -ContentType "application/vnd.vmware.vmw.rest-v1+json"

Check the API explorer for the exact request shape supported by your installed version. The API has changed less dramatically than cloud APIs, but local tool versions still matter.

Where the API fits

This is good for:

• Listing registered VMs.
• Checking basic VM state.
• Powering lab machines on or off.
• Wiring simple local scripts into repeatable lab setup.
• Avoiding click-heavy workflows before training or testing.

It is not ideal for:

• Creating fully new VMs from nothing.
• Managing large fleets.
• Replacing vCenter, ESXi APIs, or infrastructure-as-code tooling.
• Exposing VM control over a network.

The original note ended with “the functionality is a little sad”, and that is still a fair emotional summary if you expect a full virtualization-management API. But for a local lab, even small automation is useful. A script that starts the domain controller, waits, starts the clients, and shuts everything down cleanly later can save a lot of repeated clicking.

References

• VMware Workstation Pro documentation