How to Generate AI SDKs from OpenAPI with Speakeasy

Google has just open-sourced the OpenAPI client-generation tooling behind its newer GenAI SDK pipeline, making it easier to see how an API specification becomes typed client libraries, command-line tools, and Model Context Protocol (MCP) servers. The change matters beyond Google's own APIs: you can use the same workflow to turn an AI service's OpenAPI definition into a maintainable SDK instead of hand-writing HTTP wrappers. 

Why OpenAPI generation is useful for AI APIs

An OpenAPI specification is a machine-readable description of an API's endpoints, parameters, request bodies, responses, and authentication requirements. For an AI API, that contract can change quickly as new models, tools, streaming methods, and response types are added. A generated SDK turns that contract into language-specific functions and types, so application code does not have to repeatedly construct raw HTTP requests.

Google's September 17 announcement is a useful real-world example. The company said it worked with Speakeasy on SDKs for its Interactions, Agents, and Webhooks APIs and then partnered with Speakeasy to open-source the generation suite. The published generator supports Python, TypeScript, Go, Java, C#, PHP, and Ruby, along with features such as static typing, server-sent events streaming, retries, and pagination. 

What you need before generating an AI SDK

You need an OpenAPI specification for the API you want to expose and a supported target language. You should also inspect the specification before generating anything because code generation does not repair a badly designed API contract. Missing operation names, unclear response schemas, inconsistent authentication definitions, or incomplete error responses will eventually appear in the generated client.

For Google's own GenAI SDK work, the generated layer is not simply a collection of HTTP calls. The current Python client exposes resources such as interactions, agents, and webhooks, while generated interaction methods expose options for streaming, background execution, previous interaction IDs, tools, response formats, environments, and safety settings. 

Install the OpenAPI generator

The open-source project is available from Speakeasy's GitHub organization, where the repository is described as an OpenAPI SDK generator for production-ready client libraries. The project is licensed under AGPLv3. Google's announcement also says the generator suite includes an agent-native command-line generator and a documentation MCP server generator in addition to language SDK generation. 

After installing the CLI using the method appropriate for your operating system, verify that the command is available in your terminal. The important point is that the generator works from the API contract; you do not need to manually write a separate client implementation for every endpoint.

Validate your OpenAPI specification first

Before generating the SDK, validate the specification and fix warnings that describe real contract problems. This step is easy to skip because generation tools can often produce code from imperfect documents, but generated code can only be as reliable as the schema behind it. A malformed request or response definition may become a confusing type or an unusable method later.

For a practical test, use a small OpenAPI document first. A specification containing a few AI-style operations such as creating a generation request, retrieving its result, and streaming output is enough to verify that authentication, request models, response types, and streaming behavior are represented correctly.

Generate the SDK from your AI API

Once the specification validates, initialize a new SDK project with the generator's quick-start workflow. Choose the target language, SDK name, and package name. The generator then creates the client structure from the specification rather than from handwritten endpoint wrappers. Speakeasy's documented workflow uses speakeasy quickstart for new SDK projects, while the generated output can be maintained as the API evolves.

The result should contain typed models for the API's data structures and methods corresponding to its operations. That changes how application code talks to the service. Instead of assembling URLs, headers, JSON bodies, and response parsing manually, the application can call the generated client and work with language-native objects.

Connect the generated client to an AI application

After generation, install the SDK into a small test application and configure its authentication using an environment variable or another secret-management mechanism. Do not hard-code a production API key into generated source files. Then make one simple API call before adding streaming, retries, or agent tools. A successful basic request confirms that authentication, the generated endpoint, request serialization, and response parsing are all aligned.

This is particularly useful for AI APIs because their responses often contain nested objects, optional fields, enumerations, and multiple output modalities. Google's current GenAI Python SDK, for example, exposes an interaction creation method with parameters for models, agents, tools, response modalities, previous interaction IDs, environments, and structured response formats. Generated types can make those options considerably easier to discover from the programming language itself. 

Use the same API contract for AI-agent tools

The more interesting part of the new generator is what happens beyond an ordinary SDK. Google says the open-source suite can generate an agent-native CLI that lets AI coding agents invoke an API from a terminal without creating temporary HTTP scripts. It can also generate a documentation MCP server from an OpenAPI specification and documentation, giving coding agents access to current schemas instead of relying on whatever API details they happen to remember. 

That creates a useful separation of responsibilities. The OpenAPI file remains the formal description of the API, the SDK gives normal applications a typed client, the CLI gives agents a command-oriented interface, and the MCP server provides structured access to documentation. Updating the underlying contract can therefore become the trigger for updating several developer-facing surfaces rather than maintaining each one independently.

Regenerate when the API changes

Do not manually edit generated endpoint code to fix every change. Treat the OpenAPI document as the source contract and regenerate the SDK when that contract changes. Your own application-specific logic should live outside generated files so regeneration does not overwrite it.

This becomes especially valuable for AI APIs because model and tool capabilities can evolve independently of the application using them. Google's Python GenAI repository, for example, released version 2.24.0 on September 16, 2026, adding credential API resources, retrieval interaction schema support, environment file transfer features, and documentation updates for Gemini 3.8 Flash.

Where generated SDKs can still go wrong

Code generation does not remove the need for API design or testing. A generated client can faithfully reproduce an ambiguous schema, expose an endpoint whose error behavior is poorly documented, or make a breaking API change look like an ordinary package update. Streaming APIs deserve particular attention because the client must preserve event ordering and correctly handle incomplete or failed streams.

There is also a practical maintenance issue: generated code is only useful when the specification stays synchronized with the server. The safest workflow is therefore to validate the OpenAPI contract in continuous integration, generate the SDK from that versioned contract, run integration tests against the real API, and review breaking changes before releasing the new client package.

What this workflow changes for AI developers

The important shift is not that SDK generation suddenly makes API development automatic. It is that one precise API contract can now become the foundation for several AI-development interfaces. Google says its new open tooling generates SDKs for seven languages and can also produce CLIs and documentation MCP servers, while its own GenAI SDK pipeline uses the same approach across multiple API surfaces.

For an AI API project, that makes OpenAPI more than documentation. It can become the contract from which your application SDK, agent-facing tools, and developer documentation are produced. If you keep that contract accurate and regenerate from it consistently, adding a new endpoint or changing a response schema becomes a controlled software-engineering change rather than another round of hand-written client code.