How Glotto compares
An SDK is not a typed wrapper around HTTP calls. A good one auto-paginates, retries with jittered backoff, exchanges auth tokens transparently, surfaces errors as the language’s native exception type, and gives callers compile-time confidence that request shapes are correct — and it does that across a dozen languages, each with its own idea of “idiomatic.”
When you evaluate a generator, two questions decide it:
- Is the output idiomatic? — code your users would have written by hand.
- How do you keep every language correct and in parity? — so a feature isn’t silently missing in one SDK.
This page answers both, and shows where Glotto sits relative to the alternatives.
The landscape
Every tool optimizes for something. None of these is “wrong” — they make different trades.
- Open-source generators (e.g. OpenAPI Generator). Enormous language coverage, zero cost, battle-tested. The trade is output quality: generated code is functional but rarely idiomatic, so teams that care about SDK developer experience end up post-processing or customizing heavily.
- Managed platforms (Stainless, Speakeasy, Fern). Strong, polished output and a turnkey experience. The trade is control: you accept the platform’s opinion about what your SDKs look like, and the pipeline that regenerates them lives in someone else’s black box.
- Build-your-own IR frameworks (e.g. oagen). You parse the spec into a clean, fully-resolved intermediate representation and write your own emitters. Maximum control — the trade is that you build and maintain the emitters yourself.
Glotto’s bet: keep the IR-and-emitters architecture that makes output idiomatic, ship the emitters so you don’t build them, and back the whole thing with parity enforcement so “every SDK has it” is a tested guarantee rather than a hope. Plus the wedge the managed platforms don’t cover: React Native as a first-class target, GitLab/Bitbucket alongside GitHub, and a multi-mode MCP server including Code Mode.
Axis 1 — idiomatic output
The insight every serious generator shares is that you don’t template raw YAML. You parse
the spec once into a normalized, fully-resolved intermediate representation — all the
$ref chains, schema composition, and OpenAPI quirks handled centrally — and then each
language’s emitter consumes that clean data model and makes real per-language decisions.
In Glotto the IR is @glotto/core-ir: a typed model that carries
optionality, auth schemes, pagination strategy, retry config, and per-language naming as
first-class fields. The emitters consume it and decide, idiomatically:
| The IR says… | Python emits | Go emits | TypeScript emits |
|---|---|---|---|
| an optional query param | a keyword arg defaulted to None |
a pointer field on the params struct (*string) |
an optional property (name?: string) |
a oneOf |
a discriminated union | a type with a discriminator check | a discriminated union narrowed on the tag |
| a documented 4xx/5xx | an ApiError subclass |
an error type with errors.As unwrap |
an ApiError subclass |
Those aren’t template substitutions — they’re decisions encoded in hand-written emitters, which is exactly why the output reads like code a person wrote. The difference from a build-your-own framework is that Glotto ships the emitters for every supported language.
Axis 2 — code quality and cross-language parity
Idiomatic output is table stakes. The harder problem — the one that decides whether you can trust a multi-language generator — is keeping every language correct and in parity, so a capability shipped for TypeScript isn’t quietly missing in Dart.
Glotto enforces that three ways, in CI, on every change:
- Fresh-compile verification. The
@glotto/compile-verificationharness fresh-generates each SDK from the IR and compiles / type-checks it in its target language’s toolchain — not “it rendered,” but “it builds.” - Cross-language contract tests. One contract manifest of request/response scenarios is replayed by a per-language runner for every SDK against a mock server, asserting each language sends the same request and returns the same value. Behavioral parity, checked across languages from a single source of truth.
- Golden + drift gates. Every engine’s output is byte-locked by golden tests, and a dogfooded drift detection fails the build if committed output drifts from what the current generator produces.
The feature matrix — every SDK, every language
The platform plan’s §3.1.2 feature matrix is a contract: a capability listed there must exist in every generated SDK. As of the link-header-pagination and v2-timeout parity closures, all 13 SDK languages — TypeScript, React Native, Python, Go, Java, Kotlin, C#, PHP, Ruby, Swift, Rust, Dart, and Elixir — satisfy it:
| Capability | Across all 13 SDKs |
|---|---|
| Typed resources & methods | ✅ |
| Auth (Bearer, API-key, OAuth2 + PKCE) | ✅ |
| Retries with jittered exponential backoff | ✅ |
| Per-client timeouts (connect + overall) | ✅ |
| Pagination — cursor, page, offset, link-header | ✅ |
| SSE streaming with cancellation | ✅ |
| Webhook verification (HMAC / Standard / Stripe) | ✅ |
| File uploads (multipart) | ✅ |
Polling helpers (waitFor) |
✅ |
| Telemetry hooks | ✅ |
| Rich types (discriminated unions, enums, nullable distinguished from optional) | ✅ |
Typed ApiError hierarchy |
✅ |
| Per-method snippet emission | ✅ |
The surface differs idiomatically by language — async iterators in TypeScript, generators in Python, channels in Go — but the capability is the same everywhere, and the contract runners prove it.
More than SDKs
The same IR fans out beyond client SDKs: an Astro documentation site with per-language snippet tabs, a multi-mode MCP server (including Code Mode), and a Terraform provider — all regenerated together when your spec changes.
When Glotto is the right fit
- You want idiomatic, owned SDKs without writing emitters yourself.
- You ship to React Native and want a first-class target, not a browser-TS approximation.
- You live on GitLab or Bitbucket, not only GitHub.
- You want parity you can prove — compile-checked, contract-tested, drift-gated — rather than a vendor’s word for it.
Already on Stainless? See the migration guide — Glotto’s SDK languages are a superset, and migrating from Stainless converts your config in one command.