API explorer

When to use it

• You are scripting a VCF task and need the endpoint, the method and the sign-in for the product that owns it.
• You know the operation in the UI, such as commissioning hosts or rotating a password, and want the API sequence behind it.
• A script that worked on an earlier VCF fails on VCF 9, and you want to check whether the endpoint changed, as the upgrade prechecks did.

How it works

The page is one long reference with a section list on the left and a search box, Search APIs, endpoints, categories, above it. Its sections are:

• Getting started — the pattern SDDC Manager and the VCF Installer share: a bearer token from POST /v1/tokens, paths under /v1/, and long operations that return 202 with a task ID.
• API command builder — 15 SDDC Manager operations. Pick one under Operation, fill in its fields, and copy the result from the cURL, PowerShell or Python tab.
• VCF 9 API catalog — the 15 API groups as cards, each linking to its deep dive.
• Common workflows — six call sequences with an example: authenticating, commissioning hosts, creating a workload domain, rotating credentials, upgrading a domain and a new VCF deployment through the Installer.
• Deep dives — SDDC Manager (55 categories), the VCF Installer (12), then vCenter, vSAN, NSX, VCF Operations, VCF Automation, Orchestrator, Live Recovery, HCX, Data Services Manager, Identity Broker, Private AI and the Business Services console.
• Error handling — the SDDC Manager error body, HTTP status codes and common error codes such as RESOURCE_LOCK_NOT_AVAILABLE.

Expand a category and click an endpoint row. The tool builds the details for that call: Authentication (how that product signs in), Example request (a curl command with the product's host and header), Typical response for SDDC Manager calls, and Notes with a link to the product's API reference. Each product signs in its own way:

Step by step

1. Find the callType part of a path or a word into the search box, for example credentials or check-sets. The count under it shows how many endpoints match and in how many sections.
2. Read how the product signs inOpen the endpoint row and read Authentication first. The sign-in calls themselves show the credentials they send instead of a token.
3. Copy the example requestClick Copy next to Example request and replace the placeholders in braces, such as {sddc-manager-fqdn} or {session-id}. Where a call takes a body, the example sends -d @spec.json; the Notes link to the reference that defines it.
4. Or build the commandFor the 15 common SDDC Manager operations, use the API command builder: the fields fill the command in every tab.
5. Follow the async patternMost SDDC Manager changes return 202 with a task ID. Validate the spec through the matching /validations call first, then poll GET /v1/tasks/{id} until the task finishes.
6. Check errors against the referenceIf a call fails, compare the errorCode with Error handling and read the remediationMessage in the response.

Worked example

api = "https://vcf.lab/v1/system/check-sets"
headers = {"Authorization": "Bearer T0K"}

# 1. Which checks apply to the domain
query = requests.post(api + "/queries", headers=headers, verify=False,
                      json={"checkSetType": "UPGRADE", "domains": [{"domainId": "dom-1"}]})

What it doesn't do

• Send requests. It builds text for you to run. Nothing you type in the builder leaves the browser.
• List every endpoint. Categories show representative endpoints. The full list and the request and response schemas are in each product's reference, linked from every endpoint.
• Show other products' responses. Only SDDC Manager calls, and the token calls, have a typical response. For the rest, the notes point to the reference.
• Build commands outside SDDC Manager. All 15 builder operations are SDDC Manager calls.
• Give vSAN examples. The vSAN Management API is a SOAP API. Its rows are marked CALL and have no curl example; use PowerCLI Get-VsanView or the vSAN Management SDKs.
• Know your version. It covers VCF 9 and doesn't check which calls your build supports.

Common mistakes

• Calling /v1/system/prechecks. VCF 9 removed it. Use the check-sets calls, as in the example above.
• Trusting a check-set run's status alone. A run that ends COMPLETED_WITH_SUCCESS can still report critical findings. Read the results.
• Sending a bearer token to every product. vCenter, NSX, VCF Operations, HCX and Live Recovery each expect something else. Check Authentication for the endpoint.
• Rotating credentials in parallel. Password rotations must run one at a time (KB 434699), and the credentials calls need the ADMIN role.
• Asking VCF Operations for JSON without saying so. Its default answer is XML. Send Accept: application/json.
• Treating 202 as done. It means the task started. Poll it until it succeeds or fails.

Sources

• SDDC Manager API
• VCF Installer API
• vSphere Automation API
• NSX-T Data Center REST API
• VCF Operations API
• vSAN Management API

Related tools

• VCF JSON builderThe spec you send to the VCF Installer
• Day 2 operationsThe same operations as guided runbooks
• Upgrade path advisorWhich releases to upgrade through
• ESX CLI referenceCommands on the hosts themselves