Generate SDKs from your Postman collections in Six Languages

I’ve been having this experience more and more. I suspect most engineers are having it. Like I’m a nineteenth century weaver. Like I just wandered into town and saw my first power loom. I used to lovingly compose my thoughts in careful loops. Individual functions in individual files. Now I write those same thoughts into prompts that change a dozen files all at once. It’s as strange as it is awe inspiring.

Which keeps bringing me to a question: if the machine is the new weaver, what are the rails on which it runs?

Your API is about to evolve faster than it ever has. Your product will too. Internal teams and other companies are going to want to integrate at the speed of a single prompt, and that speed is exactly where things will start to come apart, drift will accumulate, and the gap between “documented” and “usable” will quietly cost everyone on the backend.

SDKs are the rails. They provide a typed, structured interface that tells any consumer, human or agent, exactly what your API does and exactly how to call it. Postman is already where developers turn to understand the truth about your API, and that’s exactly where your SDKs should come from.

In March we released our first three languages (TypeScript, Python, and Java). Today we’re excited to announce the release of three additional languages: C#, Go, and PHP.

The gap SDKs close

Here’s a pattern that plays out constantly: someone builds a well-designed API, tests it thoroughly, ships it, and watches adoption be half of what they expected. The support tickets aren’t about broken endpoints. They’re about integration. Someone in Python is serializing dates wrong. Someone in Go hand-rolled an HTTP client that doesn’t handle token refresh. Someone on the Java team copy-pasted a curl wrapper in 2019 and it’s still there.

The problem isn’t the API. It’s the friction between the developer and their first request. And agentic workflows need to be frictionless.

The companies that built developer ecosystems that actually worked (companies like Twilio and Stripe) didn’t leave that gap as an exercise for the reader. They invested in client libraries as first-class products. That investment is a large part of why they won.

An SDK does a few specific things that documentation can’t do by itself:

• Type safety. Install a package, get methods and response models your IDE understands. Errors surface at compile time, not in production at 2 AM.

• The integration tax, solved once. OAuth refresh, retry logic, pagination, binary response handling. Every API consumer either reimplements this or copies it from somewhere. An SDK does it once, correctly, for everyone.

• Synchronization. Hand-maintained client libraries drift. A generated SDK is regenerated from your spec, so when you rename a field, consumers get a pull request and not a breaking change they discover three months later.

This was already the case when humans were the only consumers of your API. Now AI agents need all the same thing human developers need: a typed, structured interface that tells them exactly what the API does and exactly how to call it. And the agents that fail at integration don’t file support tickets. They act on bad data at machine speed.

Let SDKs be the rails. How are you going to generate them?

Why generating from Postman is different

Most SDK generation tools take a static OpenAPI file. That file lives in a repo somewhere, gets updated sometimes, and may or may not reflect what your API actually does today. The SDK is only as accurate as the last time someone committed to openapi.yaml.

The Postman SDK Generator comes already built into the world’s largest API platform. Postman already acts as the public source of truth for accessing millions of APIs. By generating an SDK from Postman, you are starting from the same source that developers already trust.

When your tests, documentation, and SDK all share the same upstream Collection or OpenAPI Spec, they can all update together. Every change is versioned, reviewable, diffable. When something changes, consumers get a pull request. That’s the governance model the machine requires, and it’s available today across six languages with more on the way.

Six languages

One word on how we approached this: generated code that doesn’t pass a code review in its target language isn’t generated code, it’s a draft. Every language here has conventions that developers notice immediately when they’re violated: initialisms in Go, builder patterns in Java, Pydantic vs. dict in Python. We spent a lot of time on this before calling any of them GA, and we’re looking forward to nerding out about our approach on this blog and in our documentation.

TypeScript

TypeScript is where AI-assisted development has been most aggressive, and it’s where “just give the LLM the OpenAPI spec” fails most visibly. TypeScript developers expect types, not any. The generated SDK ships with generics, strict null handling, and async/await throughout. Response types are inferred from your spec.

import { YourApiClient } from 'your-api-sdk';

const client = new YourApiClient({ apiKey: process.env.API_KEY });

const users = await client.users.list({ limit: 50, page: 1 });

for (const user of users) {
  console.log(user.email);                    // autocomplete works here
  console.log(user.createdAt.toISOString()); // Date, not string
}

Python

Python is where SDK quality varies most wildly. When we talk to Python teams about why they don’t trust generated clients, they mean the same things: dict return types instead of Pydantic models, no type hints, sync-only support in a world that’s moved to async. The gap between a good Python SDK and a bad one is enormous and Python teams feel it acutely.

The generated SDK produces both sync and async clients using httpx, with Pydantic v2 models for request/response validation and complete type hints. Generated code passes mypy –strict out of the box.

import asyncio
from your_api_sdk import YourApiSdk, YourApiSdkAsync
from your_api_sdk.models import UserListParams

# Synchronous
sdk = YourApiSdk(api_key=os.environ["API_KEY"])
users = sdk.users.list(UserListParams(limit=50, page=1))

# Async: same model classes, different client
sdk_async = YourApiSdkAsync(api_key=os.environ["API_KEY"])

async def main():
    users = await sdk_async.users.list(UserListParams(limit=50))
    print(users)

asyncio.run(main())

Java

Java developers have seen enough generated code to know immediately when something isn’t production-grade. The tell is usually the naming, or the absence of builders, or a flat exception class where there should be a hierarchy. Teams that have been burned by this tend to hand-write their clients instead which is expensive, and lands them right back in the drift problem six months later.

The generated SDK targets Java 11+, uses builders throughout, separates checked and unchecked exceptions cleanly, and uses OkHttp for HTTP and Jackson for serialization.

YourApiConfig config = YourApiConfig.builder()
    .apiKeyAuthConfig(ApiKeyAuthConfig.builder()
        .apiKey(System.getenv("API_KEY"))
        .build())
    .build();

YourApiSdk client = new YourApiSdk(config);

UserListParams request = UserListParams.builder()
    .limit(50L)
    .page(1)
    .build();

List<User> response = client.users.list(request);
response.forEach(user -> System.out.println(user.getEmail()));

Go

Go has conventions that are enforced, not suggested. Initialisms (URL, ID, HTTP, API) must be fully uppercase. Context propagation is expected at every call site. Errors are returned, not thrown. Generated code that gets these wrong will get flagged in the first PR and shelved.

The generator normalizes to these conventions across method names, struct fields, constructors, and configuration accessors. The pointer helpers (yourapi.Ptr(int64(50))) handle the ergonomics of optional fields without requiring callers to construct pointers manually.

config := yourapi.NewConfig()
config.APIKey = os.Getenv("API_KEY")
config.Timeout = 10 * time.Second

client := yourapi.NewYourApi(config)

params := users.ListRequestParams{
    Limit: yourapi.Ptr(int64(50)),
}

resp, err := client.Users.List(context.Background(), params)
if err != nil {
    return fmt.Errorf("listing users: %w", err)
}

for _, user := range resp.Data {
    log.Printf("user %s: %s", user.ID, user.Email)
}

C#

The .NET ecosystem has specific expectations: async/await is non-negotiable, nullable reference types are expected in modern C#, and IDisposable lifetime management needs to be handled cleanly. The generated SDK targets .NET 6.0+ and manages HttpClient lifecycle internally.

using YourApi;
using YourApi.Config;
using YourApi.Models;

var config = new YourApiConfig
{
    ApiKey = Environment.GetEnvironmentVariable("API_KEY"),
    BaseUrl = "https://api.example.com"
};

var client = new YourApiClient(config);

var request = new UserListRequest { Limit = 50, Page = 1 };
var response = await client.Users.ListAsync(request);

Console.WriteLine(response);

PHP

PHP is one of the most underserved languages in the SDK generation space. Despite powering a large fraction of the web (e-commerce, CMS, the long tail of business applications that run quietly and reliably in production) quality PHP API clients that developers actually want to use are rare. Most teams either do everything by hand with a generic HTTP library, or accept generated output that doesn’t follow modern PHP conventions and quietly resent it.

The generated SDK targets PHP 8.1+ with constructor property promotion, enums, and union types. It uses Guzzle for HTTP and follows PSR-7 for message interfaces.

use YourApi\Client;
use YourApi\Models;

$sdk = new Client(
    apiKey: $_ENV['API_KEY'],
);

$response = $sdk->users->list(
    new Models\UserListParams(limit: 50, page: 1)
);

foreach ($response->getData() as $user) {
    echo $user->getEmail() . PHP_EOL;
}

// Auto-paginate
foreach ($sdk->users->listAll() as $page) {
    foreach ($page as $user) {
        process($user);
    }
}

Getting started

The SDK Generator is available on Postman Team and Enterprise plans. Generate from any Collection or API Specification.

From the app: Open your Collection or Specification → View more actions → Generate SDKs. Select languages, name your build, and download a zip or deliver directly to a GitHub pull request.

From the CLI:

# Generate a single language
postman sdk generate <collection-or-spec-id> --language go

# Generate all eight at once
postman sdk generate  \
  --language typescript \
  --language python \
  --language java \
  --language go \
  --language csharp \
  --language php

From Agent Mode: Open the right sidebar and describe what you want. Agent Mode has full context of your workspace: your Collection, your environments, your test suite, so you don’t need to know spec IDs or flag syntax.

A few prompts worth trying:

“Generate TypeScript, Go and PHP SDKs for this collection.”

“My API added three new endpoints this week. Regenerate the Go SDK and summarize what changed for consumers.”

The power loom wasn’t the end of weaving. It changed what they made, and how fast. We’re at that same inflection point now. The machine is running. SDKs are how you make sure it runs on your rails.

Read the docs →