Google and Speakeasy released the OpenAPI generation stack as open source on September 17, 2026. The openapi-generation repository contains a Go-based generator that turns OpenAPI documents into SDKs, CLI applications, MCP servers, Postman collections, and Terraform providers.
This is useful if an API team maintains separate Python and TypeScript clients while also building command-line and agent interfaces. One API specification can now feed those outputs through a public generator and reviewable templates.
What the repository generates
Google lists SDK generation for Python, TypeScript, Go, Java, C#, PHP, and Ruby. The generated libraries include static typing, Server-Sent Events streaming, retries, and pagination.
The repository documents 12 primary targets. They cover C#, Go, Java, MCP TypeScript, PHP, Python, Ruby, TypeScript, and Unity, plus CLI applications, Postman collections, and Terraform providers. It supports OpenAPI 3.0 and 3.1. Support for OpenAPI 3.2 is limited to selected constructs, so a complete 3.2 document is not yet a supported input.
The pipeline parses and validates the OpenAPI document, builds an SDK-oriented AST, loads target templates and TypeScript helpers, then renders, formats, and optionally compiles the output. That deterministic path is the main attraction. Teams can regenerate a client in CI and review the diff instead of asking a model to recreate the integration from scratch.
Why API teams should care
A single API definition can serve several developer surfaces. Application developers get language-specific SDKs, operators get a CLI, and coding agents can query an MCP server built from the same specification and Markdown documentation. Google says it used this toolchain for the new Google GenAI SDKs for the Interactions, Agents, and Webhooks APIs.
The documentation MCP generator gives agents access to current schemas rather than forcing them to guess method names from stale context. The CLI generator compiles the API into a standalone binary that an agent or developer can call from a terminal.
Quick start
For normal SDK generation, Speakeasy recommends its CLI rather than building the generator repository directly.
Install the CLI with Homebrew on macOS:
brew install speakeasy-api/tap/speakeasySpeakeasy also documents installation scripts for macOS and Linux. Review a downloaded script before running it. Windows users can install the CLI with winget install speakeasy or choco install speakeasy.
Start the interactive setup:
speakeasyAuthentication opens a browser so you can create or select a Speakeasy Platform workspace and receive an API key.
speakeasy auth loginFor CI/CD, create an API key in the platform and pass it through the SPEAKEASY_API_KEY environment variable.
Contributors working on the generator itself need Go 1.26.2, Node.js and npm, Docker, and the toolchain for each target they intend to test. The repository’s direct generation example looks like this:
go run ./cmd/generate/main.go \
-s ./tests/specs/basic-http.yaml \
-o /tmp/generated-sdk \
-l go \
--license agpl-3.0-only \
--skip-compileThe command generates a Go SDK without compiling it. On the first run, the generator writes .speakeasy/gen.yaml in the output directory.
Licensing and telemetry need an explicit decision
The generator repository uses AGPL-3.0. Under the open-source election, generated output carries AGPL-3.0-only. A commercial license token allows the generated SDK to be used, modified, distributed, and licensed under separate terms. An API team should therefore choose the artifact licensing path before putting generated clients into a product.
Google describes the generator as suitable for development and CI while letting users choose a license for generated code. The repository gives the operational detail: generation requires either an AGPL election or a commercial token. Read both before deciding that “open source” automatically fits a proprietary distribution.
Telemetry is another practical concern. Depending on the generation context, the tool may record the selected target and template, success or failure, OS and architecture, versions, configuration, and feature flags. It may also include metadata derived from a document or configuration, such as server URL, support contact, title, OpenAPI version, validation warnings, and errors. Disable it before a run when that metadata should not leave the environment:
export SPEAKEASY_DISABLE_TELEMETRY=trueStrengths and limits
The public implementation makes the generator and its templates inspectable. It also puts SDKs and agent-facing interfaces behind one OpenAPI source, which helps teams regenerate artifacts and review changes in CI.
The setup is not small. Repository development requires Go, Node.js, Docker, and target-specific runtimes. Complete OpenAPI 3.2 documents are not supported yet, and teams need to resolve the AGPL or commercial licensing choice before distribution. Sensitive specifications also warrant a telemetry review.
The commands in this article follow the official documentation and repository. The full SDK generation and compilation flow was not executed for this article.
Who should use it
The generator fits teams that publish several client SDKs from one API definition or want a CLI and MCP server to track the same schema. Platform engineers who need to inspect or customize generator templates now have a public codebase to work with.
A project with one hand-maintained client may spend more on the toolchain and license review than it saves. A weak or incomplete OpenAPI document is another reason to wait: generated clients will only be as reliable as the specification they receive.
Sources
- Google Developers Blog, Why client SDK generation belongs in the open
- Speakeasy OpenAPI Generation repository
- Speakeasy CLI Getting Started
Checked: September 20, 2026
답글 남기기