Shipping SDK changes across seven languages in under 30 minutes
Hand-maintaining SDKs is painful, and outsourcing them is worse. Here's the open-source tool and CI safeguards WorkOS uses to ship SDK changes safely.
If you ship an API, you ship SDKs. We maintain seven of them, and keeping all seven consistent used to be manual work: every new endpoint meant edits across seven repositories, in seven sets of conventions, with drift and stale docs as the reward for falling behind.
We already solved the generation half of that problem. A single OpenAPI spec feeds two open-source tools — oagen, which parses the spec into a normalized intermediate representation, and oagen-emitters, which turns that IR into idiomatic code per language, with Claude scoped narrowly to language-specific translation. Generating the code is the easy part.
The hard part is everything after: taking a spec change through generation, validation, and release across seven languages without shipping something that breaks a customer's build. Hand-maintaining SDKs is painful. Handing that job to a third-party vendor and living on their roadmap is worse. So we built our own tool to run the pipeline.
Keeping the public spec honest
The team drives the pipeline from a dashboard: it shows the open sync PRs, runs validations and test builds, auto-merges when builds are green, and flags issues when something breaks. You can select specific API sections to generate, preview a run through staged generation with GitHub workflow checks, override generated names and methods, and generate a changelog before anything ships.
Everything the dashboard does is also callable without a browser. The same operator actions are exposed over a REST API, to MCP clients, and through Slack. That means a scripted caller, or an agent, can drive the exact same release flow a human clicks through.
Choosing what ships
Once the public spec is current, you choose what belongs in the next SDK release.
The dashboard groups available changes by category and gives each one a concise summary, along with a link to the source PR where it originated. You can ship one change or bundle several into a single coordinated release.
Dry runs that leave no trace
Before creating anything real, you can run the entire release as a preview.
The dashboard attempts to generate every SDK for the exact set of features you selected, backed by the same GitHub workflow used for a live release. As the builds finish, their results stream back into the dashboard.
The key difference is that a dry run opens no pull requests and leaves nothing behind. It exercises the real build process without producing any durable changes. It’s a second check of the same OpenAPI build path that already ran during the spec sync.
When the preview passes, the dashboard renders the proposed SDK changes in a diff viewer. You can inspect exactly what would land before anything touches a repository.
And if the generator chooses a name or method signature that doesn’t feel right, you can override it. Anything produced automatically can still be adjusted by hand. Generation handles the mechanical 95%; the dashboard keeps the consequential 5% under human control.
Changelogs written for humans
We have roughly 200 API endpoints, and the people who most need to know when those change are the developers building on our SDKs.
Whenever the spec changes, the spec repo's CI pushes each commit's per-service changelog entries, along with a spec-changes manifest. The dashboard reads that to compute which services are pending generation, without needing any live GitHub access. When it renders, entries land in a fixed order — Breaking, then Features, then Fixes — and the tool computes a conventional-commit rollup title (feat! → feat → fix) from the same entries, so the PR title names the most consequential change first. Downstream users get a consistent, categorized record of what moved in every release.
Shipping the batch
Once you generate a live batch, the dashboard opens real pull requests across all seven SDK repositories. Each PR includes the changelog you prepared and remains pending while its test suite runs.
From there, you can merge each repository individually—or click Merge All and watch the releases land together.
Two things guard the actual release. First, the release step is backed by OIDC, so publishing leans on short-lived, workload-scoped identity instead of long-lived publish tokens sitting in CI. Second, automation stops short of the last step: after the SDK PRs merge and their statuses turn green, a final release gate still requires a human on the DAX team to merge before the changes go live. Fast where it's safe, manual where it counts.
Try it
oagen, oagen-emitters, and our OpenAPI spec are all open source. If you maintain client libraries across several languages, you don't have to choose between babysitting them by hand and outsourcing them to a vendor. Own the pipeline, put the safeguards where they matter, and let the boring 30 minutes take care of itself.