VCF 9.1 API with Postman: Generate a Collection from OpenAPI and Automate Your First Workflow

TL;DR

VMware Cloud Foundation 9.1 provides an OpenAPI definition for SDDC Manager that can be imported into Postman to generate a structured collection of API requests.

The generated collection is not immediately ready for use. The specification defines a localhost server value, so the requests must be updated to use a variable that points to your SDDC Manager appliance. You also need to configure bearer-token authentication, protect credentials, and isolate a small read-only workflow from the larger collection.

This walkthrough builds a practical three-request sequence:

• create an SDDC Manager access token
• retrieve the VCF domain inventory
• save a selected domain ID and retrieve that domain by ID

The result is a working automation prototype that can be tested before you invest in a PowerShell, Python, Java, or SDK-based application.

Introduction

The distance between clicking through SDDC Manager and building a production API application is wider than it first appears.

An administrator may know exactly what needs to be automated but still be blocked by authentication, request construction, response models, environment variables, and unfamiliar error handling. Starting with a complete application can add unnecessary complexity before the engineer has even proven that the required API sequence works.

Postman fills that middle ground.

It provides a controlled environment for discovering endpoints, testing authentication, inspecting JSON responses, chaining requests, and adding assertions. The VCF 9.1 OpenAPI package makes the process faster because Postman can generate much of the request catalog directly from the published specification.

This article focuses specifically on the SDDC Manager API. The VCF 9.1 API package includes definitions for multiple VCF components, but a focused SDDC Manager workflow is a better place to learn the authentication and request patterns.

What You Will Build

By the end of this walkthrough, you will have:

• downloaded or cloned the official VCF 9.1 API specifications
• located the SDDC Manager OpenAPI definition
• imported the definition into Postman
• generated a collection organized by API tags
• replaced the generated localhost server with a reusable base URL
• configured collection-level bearer authentication
• created and saved an access token
• retrieved the VCF domain inventory
• selected a domain by name or default position
• saved the domain ID for another request
• retrieved and validated a specific domain
• run the workflow as a controlled collection sequence

This is not intended to replace a full automation application. It is a validation layer that helps you understand the API before you write one.

The Workflow at a Glance

The OpenAPI import generates individual requests. The actual workflow appears only after you add variables, authentication, scripts, and sequencing.

The distinction matters. OpenAPI removes much of the manual request-authoring work, but it does not decide which operations are safe, how credentials should be handled, or how requests should depend on one another.

Scope and Assumptions

This walkthrough makes the following assumptions:

• VCF 9.1 and SDDC Manager are already deployed.
• The workstation running Postman can resolve and reach SDDC Manager.
• The account can authenticate and read domain inventory.
• Testing begins in a lab or controlled nonproduction environment.
• The initial workflow remains read-only after token creation.
• Internal certificate trust is handled correctly.
• Postman is being used for discovery and validation, not as the final production orchestration platform.

The imported collection exposes much more than the three operations used here. Do not run the entire generated collection against a live environment.

Prerequisites

You need:

• access to a VCF 9.1 SDDC Manager appliance
• an account with the required API permissions
• Postman Desktop, or Postman Web with the appropriate desktop agent
• the VCF 9.1 API specification package
• DNS and routing access to the management network
• the internal certificate authority chain, when SDDC Manager does not use a publicly trusted certificate
• basic familiarity with HTTP methods, status codes, JSON, and bearer tokens

Before testing, confirm that the account is not a broadly shared administrative identity. A dedicated lab or automation account is easier to audit and revoke.

Download the VCF 9.1 API Specification

The official VCF 9.1 API package contains OpenAPI definitions for SDDC Manager and several additional VCF components.

Download the 9.1 package from the Broadcom Developer Portal, or clone the official repository when you want a source-controlled copy.

Locate the following file:

specifications/
└── sddc-manager/
    └── sddc-manager-openapi.json

The specification identifies itself as:

OpenAPI version: 3.0.1
API title: SDDC Manager API Reference Guide
API version: 9.1.0.0

Keep the specification version with your collection documentation. If the VCF environment is upgraded later, compare the collection against the updated API definition before assuming paths, properties, or response models are unchanged.

Import the OpenAPI Definition into Postman

Open Postman and select the import option.

Choose the SDDC Manager OpenAPI JSON file. Postman can import it in two useful ways.

Import as a Postman Collection

This creates a collection containing folders, requests, and response examples.

Use this for:

• individual testing
• lab exploration
• short-lived validation
• quick proof-of-concept workflows

Import as a Specification with a Collection

This creates a specification in Postman and generates a linked collection.

Use this for:

• team-managed API work
• longer-lived collections
• specification synchronization
• reviewing changes between OpenAPI versions

For a maintained collection, the linked specification approach is preferable because it makes drift between the OpenAPI document and the generated collection more visible.

Configure the Collection Generation Options

When Postman presents generation options, use the following starting point:

• organize folders by tags
• derive request names from summaries or operation IDs
• include response examples
• leave optional parameters disabled unless needed
• exclude deprecated operations from the first working collection
• review generated authentication rather than trusting it automatically

Folder organization by tags makes areas such as Tokens, Domains, Tasks, Hosts, and Certificates easier to navigate.

Rename the collection to:

VCF 9.1 SDDC Manager API - Generated

Create a new folder inside the collection:

00 - First Read-Only Workflow

Copy only the following generated requests into that folder:

Create Token Pair
Get Domains
Get Domain

This reduces the risk of accidentally running unrelated write operations.

Replace the Generated Localhost Server

The SDDC Manager OpenAPI definition includes a localhost server value. Postman may use that value when it generates request addresses.

Do not edit every request with a hard-coded appliance name. Replace the generated server with a variable.

Create a Postman environment named:

VCF 9.1 Lab

Add these variables:

Update the requests to use:

{{base_url}}/v1/tokens
{{base_url}}/v1/domains
{{base_url}}/v1/domains/{{domain_id}}

Select the VCF 9.1 Lab environment before sending requests.

Protect Credentials and Tokens

Environment variables make testing convenient, but they should not become an excuse for weak secret handling.

At minimum:

• do not place credentials directly in the collection
• do not commit populated environment exports to source control
• do not share an environment containing a live password
• remove active tokens before exporting the collection
• invalidate refresh tokens when testing is complete, when required
• use a dedicated automation or lab account
• limit the account to the permissions required by the workflow

Postman Local Vault can be used for passwords and other sensitive values that should remain on the local application and workstation. Enterprises with an approved external vault should use that integration instead of maintaining shared plaintext secrets.

The examples below use environment variables to make the workflow easy to understand. Adapt the secret-handling implementation to your organization’s security policy.

Configure Collection-Level Authentication

Open the generated collection and configure its authorization settings.

Use:

Authorization type: Bearer Token
Token: {{access_token}}

Configure the two domain requests to inherit authorization from the collection.

Configure the token request as:

Authorization type: No Auth

The token request cannot depend on the bearer token it is responsible for creating.

Collection-level authentication is preferable to configuring each request independently because it creates one visible and maintainable authentication boundary.

Create the Access Token Request

Rename the first request:

01 - Create Access Token

Configure the request:

Method: POST
Request: {{base_url}}/v1/tokens
Authorization: No Auth
Content-Type: application/json
Accept: application/json

Use this request body:

{
  "username": "{{username}}",
  "password": "{{password}}"
}

A successful VCF 9.1 token request returns HTTP status 201 Created and a token pair containing an access token and refresh-token identifier.

Add this post-response script:

pm.test("Token request returned 201", function () {
    pm.response.to.have.status(201);
});

const body = pm.response.json();

pm.test("Access token was returned", function () {
    pm.expect(body.accessToken).to.be.a("string");
    pm.expect(body.accessToken.length).to.be.above(0);
});

pm.environment.set("access_token", body.accessToken);

if (body.refreshToken && body.refreshToken.id) {
    pm.environment.set(
        "refresh_token_id",
        body.refreshToken.id
    );
}

What the Script Does

The script:

• confirms the expected status code
• parses the JSON response
• verifies that an access token exists
• saves the access token into the active environment
• saves the refresh-token identifier when present

What You Need to Change

Populate:

username
password
base_url

Confirm that the correct Postman environment is selected before sending the request.

What Success Looks Like

You should see:

• HTTP status 201
• a populated accessToken property
• a populated access_token environment variable
• a populated refresh_token_id variable
• two passing Postman tests

Retrieve the VCF Domain Inventory

Rename the second request:

02 - Get Domains

Configure it as:

Method: GET
Request: {{base_url}}/v1/domains
Authorization: Inherit auth from parent
Accept: application/json

The response contains an elements array and pagination metadata.

Add this post-response script:

pm.test("Domains request returned 200", function () {
    pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("Response contains domains", function () {
    pm.expect(body.elements).to.be.an("array");
    pm.expect(body.elements.length).to.be.above(0);
});

const targetName =
    pm.environment.get("target_domain_name");

let selectedDomain;

if (targetName) {
    selectedDomain = body.elements.find(
        domain => domain.name === targetName
    );
} else {
    selectedDomain = body.elements[0];
}

pm.test("A domain was selected", function () {
    pm.expect(
        selectedDomain,
        "No domain matched the requested selection"
    ).to.exist;
});

if (selectedDomain) {
    pm.environment.set(
        "domain_id",
        selectedDomain.id
    );

    pm.environment.set(
        "domain_name",
        selectedDomain.name
    );

    console.log(
        `Selected domain: ${selectedDomain.name}`
    );

    console.log(
        `Saved domain_id: ${selectedDomain.id}`
    );
}

How Domain Selection Works

When target_domain_name contains a value, the script searches for an exact domain-name match.

When target_domain_name is empty, the script selects the first returned domain.

The fallback makes the example immediately testable, but deterministic selection is safer. For a durable workflow, populate target_domain_name and fail when the expected domain is not found.

What Success Looks Like

You should see:

• HTTP status 200
• a populated elements array
• a passing domain-selection test
• domain_id populated in the environment
• domain_name populated in the environment
• the selected domain logged in the Postman Console

Retrieve the Selected Domain

Rename the third request:

03 - Get Domain by ID

Configure it as:

Method: GET
Request: {{base_url}}/v1/domains/{{domain_id}}
Authorization: Inherit auth from parent
Accept: application/json

Add this validation script:

pm.test("Domain request returned 200", function () {
    pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("Returned domain matches the saved ID", function () {
    pm.expect(body.id).to.eql(
        pm.environment.get("domain_id")
    );
});

const expectedName =
    pm.environment.get("domain_name");

if (expectedName) {
    pm.test(
        "Returned domain matches the saved name",
        function () {
            pm.expect(body.name).to.eql(
                expectedName
            );
        }
    );
}

This request proves that data captured from one API response can drive the next request without manual copying.

What Success Looks Like

You should see:

• HTTP status 200
• the expected domain object
• a matching domain ID
• a matching domain name
• all Postman tests passing

Run the Workflow as a Sequence

Place the requests in this order:

00 - First Read-Only Workflow
├── 01 - Create Access Token
├── 02 - Get Domains
└── 03 - Get Domain by ID

Open the folder in the Collection Runner.

Select:

Environment: VCF 9.1 Lab
Iterations: 1

Run only the workflow folder, not the entire generated collection.

Review both the runner results and the Postman Console.

A green runner result confirms that the scripted assertions passed. It does not prove that the same account, certificate handling, or workflow design is appropriate for production.

Validation Checklist

Capture these results with the collection version, VCF version, appliance target, test date, and account role. That record becomes useful when the workflow is rewritten in another language.

Common Problems and Practical Fixes

Requests Still Target Localhost

Symptom: The generated request reaches the local workstation or fails immediately.

Likely cause: The OpenAPI-generated server address was not replaced.

Fix: Confirm that the request starts with {{base_url}} and inspect the resolved request in the Postman Console.

Base URL Contains an Extra Path or Slash

Symptom: The request contains a duplicated path separator or repeats part of the API path.

Likely cause: base_url contains an API suffix instead of only the appliance root address.

Fix: Store only the SDDC Manager root address in base_url. Keep /v1/... in each request.

DNS Resolution or Connection Timeout

Symptom: Postman cannot resolve or connect to SDDC Manager.

Likely cause: The workstation lacks DNS resolution, routing, VPN access, or management-network reachability.

Fix: Validate the network path from the workstation. When using Postman Web, confirm that the desktop agent is selected and can reach the private endpoint.

Certificate Validation Failure

Symptom: The request fails with a certificate or self-signed certificate error.

Likely cause: Postman does not trust the certificate authority that issued the SDDC Manager certificate.

Fix: Import the internal CA certificate into Postman. Disabling certificate verification may help isolate a lab issue, but it should not become the permanent solution.

Token Request Returns 400

Symptom: The token request returns a bad-request response.

Likely causes:

• malformed JSON
• missing credential variables
• incorrect username format
• wrong content type
• unresolved Postman variables

Fix: Inspect the resolved request body in the Postman Console. Confirm that the active environment contains the required values.

Do not log the password while troubleshooting.

Domain Request Returns 401

Symptom: Token creation succeeds, but the domain request is unauthorized.

Likely causes:

• access_token was not saved
• the request overrides collection authorization
• the wrong environment is active
• the token expired

Fix: Re-run the token request and confirm that the domain request inherits bearer authentication from the collection.

Domain Request Returns 403

Symptom: Authentication succeeds, but access to the endpoint is forbidden.

Likely cause: The account is valid but lacks authorization for the requested operation.

Fix: Review the assigned role and scope. Do not automatically grant broad administrative rights simply to make the request pass.

No Domain Matches the Target Name

Symptom: The domain request succeeds, but the domain-selection test fails.

Likely causes:

• target_domain_name does not match exactly
• the variable contains extra spaces
• the wrong environment is active
• the expected domain is not visible to the account

Fix: Inspect the returned elements array and copy the exact domain name into the environment.

Runner Uses Stale Variables

Symptom: Requests work manually but fail in the Collection Runner.

Likely cause: The runner uses a different environment or conflicting variable scope.

Fix: Select the environment explicitly and remove duplicate values from collection, environment, and local scopes.

Add a Reusable Error Diagnostic

The VCF error model can include a message, remediation message, nested errors, and a reference token. The reference token is especially useful when an issue must be escalated.

Add this script to requests where additional diagnostics would help:

if (pm.response.code >= 400) {
    let errorBody;

    try {
        errorBody = pm.response.json();
    } catch (error) {
        console.error(
            "Response was not valid JSON",
            pm.response.text()
        );
    }

    if (errorBody) {
        console.error({
            status: pm.response.code,
            errorCode: errorBody.errorCode,
            message: errorBody.message,
            remediationMessage:
                errorBody.remediationMessage,
            referenceToken:
                errorBody.referenceToken
        });
    }
}

Do not treat console output as a substitute for secure centralized logging. The purpose is to expose useful evidence during API discovery.

Operational Guardrails for the Generated Collection

The imported SDDC Manager collection includes both read and write operations. Some operations can initiate tasks that modify hosts, domains, certificates, credentials, lifecycle state, or other critical platform components.

Apply these controls before expanding the workflow:

• keep read-only discovery requests in a separate folder
• keep write requests in a clearly marked folder
• maintain separate lab and production environments
• use distinct credentials for experimentation and production
• add tests for required variables before sending requests
• require deterministic object selection
• fail when a search returns zero or multiple unexpected matches
• capture task IDs from asynchronous operations
• poll task status rather than assuming acceptance means completion
• document expected rollback or recovery actions
• require change approval before enabling state-changing requests
• export collections without passwords, tokens, or production targets

A generated collection is an API inventory. It becomes an operational tool only after its execution boundaries are intentionally designed.

When to Move Beyond Postman

Postman is a strong fit for:

• endpoint discovery
• authentication validation
• request prototyping
• response inspection
• schema exploration
• workflow demonstrations
• test assertions
• handoff between administrators and developers

Move the workflow into PowerShell, Python, Java, or an approved SDK when you need:

• repeatable execution across multiple environments
• structured logging and centralized observability
• idempotent operations
• formal retry and timeout handling
• asynchronous task polling
• source-controlled configuration
• pipeline-based execution
• external secret management
• automated rollback
• unit and integration testing
• concurrency or large-scale inventory processing

The Postman work is not discarded. The requests, payloads, tests, response samples, and failure evidence become the implementation contract for the script or application that follows.

Practical Next Steps

After the first workflow is stable:

1. Make target_domain_name mandatory.
2. Add token-refresh handling.
3. Add refresh-token invalidation after testing.
4. Retrieve clusters associated with the selected domain.
5. Add reusable error parsing.
6. Export a sanitized collection and environment template.
7. Run the collection through an approved command-line runner.
8. Reimplement the proven workflow in PowerShell or Python.
9. Add structured logging and secret-manager integration.
10. Introduce a controlled asynchronous task workflow in a lab.

Preserve the same operational pattern as the workflow grows:

Conclusion

The VCF 9.1 OpenAPI package lowers the barrier to useful SDDC Manager automation. Instead of manually discovering every endpoint and constructing each request from scratch, an engineer can generate a Postman collection and begin testing against a controlled environment.

The import is only the starting point. A dependable workflow still requires a corrected base URL, protected credentials, explicit bearer authentication, deterministic object selection, narrow execution folders, and response assertions.

The three-request workflow in this article provides a practical first milestone. It creates a token, retrieves the domain inventory, saves a domain ID, and validates that domain through a second request.

That is enough to prove the authentication and request-chaining model before moving into a larger automation application. It also creates a repeatable set of evidence that can guide a later PowerShell, Python, Java, or SDK implementation.

External References

• Broadcom Developer Portal: VCF API Specification
  Canonical URL: https://developer.broadcom.com/sdks/vcf-api-specification/latest
• VMware GitHub: vmware/vcf-api-specs
  Canonical URL: https://github.com/vmware/vcf-api-specs
• VMware GitHub: sddc-manager-openapi.json
  Canonical URL: https://github.com/vmware/vcf-api-specs/blob/main/specifications/sddc-manager/sddc-manager-openapi.json
• Broadcom Developer Portal: Create Token | VMware Cloud Foundation API
  Canonical URL: https://developer.broadcom.com/xapis/vmware-cloud-foundation-api/latest/v1/tokens/post/
• Broadcom Developer Portal: Get Domains | VMware Cloud Foundation API
  Canonical URL: https://developer.broadcom.com/xapis/vmware-cloud-foundation-api/latest/v1/domains/get/
• Broadcom Developer Portal: Get Domain | VMware Cloud Foundation API
  Canonical URL: https://developer.broadcom.com/xapis/vmware-cloud-foundation-api/latest/v1/domains/id/get/
• Postman Docs: Import an API specification
  Canonical URL: https://learning.postman.com/docs/design-apis/specifications/import-a-specification
• Postman Docs: Generate collections from your API specification
  Canonical URL: https://learning.postman.com/docs/design-apis/specifications/generate-collections
• Postman Docs: Store secrets in Postman Vault
  Canonical URL: https://learning.postman.com/docs/use/postman-vault/postman-vault-secrets
• Postman Docs: Add and manage CA and client certificates in Postman
  Canonical URL: https://learning.postman.com/docs/use/send-requests/authorization/certificates

The post VCF 9.1 API with Postman: Generate a Collection from OpenAPI and Automate Your First Workflow appeared first on Digital Thought Disruption.