SDK generation for VCF APIs using OpenAPI Specifications

Starting with VMware Cloud Foundation (VCF) 9.0, VMware officially publishes OpenAPI specifications for VCF APIs. This is a major milestone for developers, enabling you to consume VCF APIs using your programming language of choice.

VMware provides first-class developer tooling such as VCF PowerCLI for PowerShell users and the VCF SDK offering Java and Python bindings. These out-of-the-box options may not cover all the developers wanting to consume VCF in their preferred programming language. In such scenarios, you can generate custom, strongly-typed API client libraries directly from the published OpenAPI specification.

This guide walks through the end-to-end process of generating a custom .NET C# API client using OpenAPI Generator. Beyond basic CLI usage, we will address real-world edge cases such as handling massive spec sizes and scoping API surfaces.

OpenAPI Specifications

The OpenAPI specification defines an open-source, machine readable, language agnostic API contract. It serves as a single source of truth, documenting API operations, components, and schema details in a machine-readable format. Because the specification is generated once by the API producer, developers can feed that same contract into various generator tools (OpenAPI Generator, Kiota, TypeSpec, or AutoRest) to produce native client bindings in their preferred programming language.

Installing OpenAPI Generator

OpenAPI Generator is a widely adopted, Java-based CLI tool capable of producing client SDKs across dozens of target languages. Because it runs on Java, ensure you have JRE/JDK 11 or higher installed on your system (unless you run it via Docker).

Installation Methods

1. Node.js / NPM (Recommended for CI/CD & Full-Stack):

# Global installation
npm install -g @openapitools/openapi-generator-cli

# Local project dev-dependency
npm install –save-dev @openapitools/openapi-generator-cli

2. OS Package Managers

# macOS / Linux via Homebrew
brew install openapi-generator

# Windows via Scoop
scoop install openapi-generator-cli

3. Docker

docker pull openapitools/openapi-generator-cli

4. Standalone Executable JAR

# Download from Maven Central
wget https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/7.4.0/openapi-generator-cli-7.4.0.jar -O openapi-generator-cli.jar

# Run directly
java -jar openapi-generator-cli.jar generate -i spec.yaml -g csharp -o ./sdk

Generating a .NET Client for vSphere APIs

To demonstrate client generation for a real vSphere environment, we will target two distinct vSphere endpoints:

vSphere Automation REST API (/api): A modern, resource-oriented REST API for core inventory objects such as virtual machines, datastores, folders, and resource pools.
Virtual Infrastructure JSON API (/sdk/vim25): A JSON-RPC equivalent of the classic SOAP API endpoint, offering complete API coverage across core vSphere and vSAN capabilities.

Here is the OpenAPI generator command that will generate the .Net CSharp client SDK for both these API interfaces.

_JAVA_OPTIONS=”-DmaxYamlCodePoints=99999999″ openapi-generator-cli generate \
    -i vsphere-automation-spec.yaml \
    -g csharp \
    -o ./InternalOpenApi \
    -t ./templates/csharp \
    –additional-properties targetFramework=net8.0,library=restsharp,nullableReferenceTypes=true \
    –global-property apis=”CisSession:VcenterDatastore:VcenterFolder:VcenterResourcePool:VcenterVM”,models,supportingFiles,tests=false

Let us understand the command and its provided argument in detail.

Increase JVM Memory Limits for vSphere OpenAPI Specifications

When parsing enterprise-scale specs, the generator’s underlying YAML parser (SnakeYAML) will crash if the document exceeds its default safety limit (~3 MB of code points).

To prevent memory limit exceptions, pass the maxYamlCodePoints system property directly to the JVM before invocation:

_JAVA_OPTIONS=”-DmaxYamlCodePoints=99999999″

Specify the Generator and Targeted Framework

The OpenAPI C# generator supports multiple underlying HTTP clients (such as RestSharp and HttpClient). Here, we target RestSharp, pinning the build target to .NET 8.0 with nullable reference types enabled:

–additional-properties targetFramework=net8.0,library=restsharp,nullableReferenceTypes=true

Trim the API Scope for SDK Generation

Full product specifications for vSphere describe hundreds of operations. Compiling a massive, monolithic client when your application only needs a fraction of those endpoints inflates build times and produces unnecessarily large binaries.

Use the –global-property apis flag to filter generation down to only the specific API groups you require:

–global-property apis=”CisSession:VcenterDatastore:VcenterFolder:VcenterResourcePool:VcenterVM”,
models,supportingFiles,tests=false

Project Structure & Application Integration

Generating SDKs separately for both the REST API (/api) and the VI/JSON API (/sdk/vim25) produces two clean, independent C# projects. Keeping these bindings in separate packages prevents namespace and class collisions on overlapping entities (e.g., a “VM” or “Folder” has distinct structural definitions in each spec).

1. Referencing Projects in .csproj

In your consuming solution, reference both generated output directories as standard project dependencies:

<itemgroup>
  <projectreference include="InternalViJson/src/Vcenter.ViJson.OpenApi/Vcenter.ViJson.OpenApi.csproj" />
  <projectreference include="InternalOpenApi/src/Vcenter.Automation.OpenApi/Vcenter.Automation.OpenApi.csproj" />
</itemgroup>

2. Calling APIs from generated Client SDK

Since you have generated SDKs offerring API bindings you can interact with the APIs in your application code with strongly-typed C# classes and methods. Here is the sample code usage from the generated SDK.

using Vcenter.Automation.OpenApi.Api;
using Vcenter.Automation.OpenApi.Client;

// Initialize configuration and client session
var config = new Configuration { Host = “https://vcenter.local/api” };
var sessionApi = new CisSessionApi(config);

// Application logic uses clean, strongly-typed operations
var vmApi = new VcenterVMApi(config);
var vmList = await vmApi.ListAsync();

Conclusion

Publishing complete OpenAPI specifications marks a pivotal shift in how enterprise private clouds are managed. Rather than treating VMware Cloud Foundation as a series of isolated control panels or limiting integration to pre-selected SDK languages, VCF becomes a fully programmable infrastructure platform.

By publishing OpenAPI contracts, VCF establishes an API-first paradigm where the specification itself is the single source of truth. Whether your developer teams build in C#, Go, Rust, TypeScript, or Swift, language choice is no longer a blocker. If a language compiler or HTTP stack exists, client code can be generated in seconds.

The end result is an agile, friction-free developer experience. Whether you’re managing multi-tenant clouds, automating internal platforms, or building custom orchestration tools, OpenAPI specifications ensure VMware Cloud Foundation can be extended, integrated, and consumed seamlessly from any programming language interface.

Resources

Discover more from VMware Cloud Foundation (VCF) Blog

Subscribe to get the latest posts sent to your email.