Ship API changes without breaking SDKs—preview builds show you exactly what will happen

Stainless preview builds solve the biggest problem blocking API development at scale: engineers can't see how their OpenAPI changes affect SDKs until after they ship. Now you and your team can see exact SDK diffs and test locally without leaving your pull request (PR).

The real problem: API teams become the bottleneck

At most companies, shipping API updates looks like this:

• Engineer updates OpenAPI spec, hopes it's right

• Can't see SDK impact without merging to main

• Either merges and hopes, or asks API platform team to verify

• Discovers breaking changes only after SDKs regenerate in production

• Customers complain as hotfixes are rushed out the door

This creates a bottleneck where either:

1. A single API platform team handles all updates across the organization

2. Or product teams make "blind" changes and hope nothing breaks downstream

Without a clear line of sight into SDK changes, PRs that update your OpenAPI spec can be harrowing. The feedback loop is often too long, the risks can be too high, and the tooling knowledge might be too specialized. The best path forward could be a less-than-ideal workaround that avoids changing the API.

But what if there was a better way?

See SDK changes instantly, right in your PR

Preview builds allow you to see upcoming SDK changes in the pull request itself. Instead of guessing how your OpenAPI changes will ripple through SDKs, you see the exact diffs before anything hits main.

How preview builds work

When you open a PR that changes your OpenAPI spec in the source repo, Stainless will automatically:

1. Build all your SDKs in the background

2. Comment on the PR with complete diffs showing exactly what will change

3. Provide installation instructions to test your TypeScript, Python, and Go SDKs locally

4. Surface any new errors or diagnostics

5. Include an editable commit message for the final publish

Nikhil Benesch, Software Engineer, turbopuffer

Designed for PR-first workflows

Preview builds are built for teams who use GitHub pull requests or GitLab merge requests to make changes to their OpenAPI spec. Once the Stainless GitHub Action is installed, previews run automatically on every relevant PR.

Example: Add descriptions to your schema, and Stainless will preview how they render in each SDK, with diffs and a default commit message like docs: add description to schema props.

Alternative: push-based workflows

If you don’t use PRs to update your OpenAPI spec, Stainless supports push updates through GitHub Actions, GitLab CI, or URL polling. These options are simpler to set up and work well for projects that commit directly to main, but they don’t offer previews or an interactive review like the PR flow does.

The compound effect

Preview builds aren't just about seeing diffs. They fundamentally change how you can ship APIs:

1. Democratization: instead of 3 people who can update APIs, you have 300 (or 3,000)

2. Velocity: confidently ship API changes in minutes, not days

3. Quality: see breaking changes before customers do

4. Adoption: engineering teams will be excited, not hesitant, to contribute to APIs

Preview builds bring full visibility into how your spec changes will ripple through every SDK, right inside your PR. That means no manual regeneration, no surprise type churn, and no risky merges. You get reliable, fast feedback where it matters most, while you’re still iterating.

Preview builds have been really helpful in shortening the external-API iteration cycle for us. We initially just needed a CI lint, but we've used the links to the preview Studio and diff a lot.

—Vishal Devireddy, Software Engineer, Scorecard

Get started

Preview builds are available now for all Stainless users. Setup takes only a few minutes:

1. Install the Stainless GitHub Action (also supports GitLab!)

2. Open a PR with a spec change

3. See your SDK diffs instantly

Get started with preview builds.