Three tools generate a Rust SDK from OpenAPI in 2026: progenitor, OpenAPI Generator's rust template, and paperclip. Our recommended default is OpenAPI Generator's rust generator (reqwest library) for general use, with progenitor as the better pick if your spec comes from a Dropshot-based Rust API or you want more idiomatic output and can tolerate rough edges. Sourced doesn't generate a Rust SDK — so this post covers the OSS path end to end; see "Where Sourced fits" below for what it does cover.
Rust SDK generators compared
| Tool | Maintained (Sept 2026) | Best fit | Caveat |
|---|---|---|---|
OpenAPI Generator (rust) |
Yes — v7.25.0, released Aug 24 2026 | General-purpose, any valid OpenAPI 3.0/3.1 spec | Generated code reads like generated code, not hand-written Rust |
| progenitor | Yes — active commits within days, v0.15.0 latest tag | Specs from Dropshot-generated APIs; teams wanting idiomatic output | Its own docs say it "may fail for some OpenAPI documents" outside its target case |
| paperclip | Slower-moving — last release v0.9.7 (April 2026), own README calls it "under active development and may not be ready for production use" | Projects already using paperclip for server-side codegen too | Not recommended as a new default as of September 2026 |
Option 1: OpenAPI Generator (recommended default)
OpenAPI Generator's Rust support (generator name rust) defaults to the reqwest HTTP client library, with reqwest-trait, hyper, and hyper0x also available. It's part of the same actively maintained multi-language project used for the TypeScript and Python generators covered elsewhere on this blog — same release cadence, same CLI shape.
npx @openapitools/openapi-generator-cli generate \
-i ./openapi.yaml \
-g rust \
-o ./generated \
--additional-properties=packageName=my_api_client,library=reqwest
This is the safer default if your spec isn't produced by a Dropshot service, because OpenAPI Generator's Rust templates are exercised against a much wider variety of real-world specs than progenitor's are. The trade-off is idiom: the output looks like generated Rust, with builder-pattern request construction rather than the more ergonomic surface progenitor produces for its target case.
Option 2: progenitor
progenitor is built by Oxide Computer and is most at home generating clients for APIs whose specs were themselves produced by Dropshot, Oxide's Rust web framework. It's actively developed — commits landed within the last two days of this writing, with v0.15.0 the latest tagged release.
cargo install cargo-progenitor
cargo progenitor -i ./openapi.json -o my-api-client -n my-api-client -v 0.1.0
progenitor also supports generating inline via a build.rs script or the generate_api! macro, for teams that want the client compiled directly into their crate rather than checked in as generated source.
The honest caveat, from progenitor's own documentation: "Progenitor may fail for some OpenAPI documents." It's tuned for Dropshot's OpenAPI output specifically; if your spec comes from a different framework, test it against progenitor before committing, and expect to file an issue if it chokes on a construct Dropshot never produces.
Option 3: paperclip
paperclip does both server- and client-side Rust codegen plus OpenAPI spec tooling, but as of September 2026 it's the slowest-moving of the three — its last release (v0.9.7) shipped in April 2026, and its own README still describes it as "currently under active development and may not be ready for production use just yet." That's paperclip's own characterization, not ours. If you're not already invested in paperclip for server-side generation, start with OpenAPI Generator or progenitor instead.
Recommended default, and why
For most teams generating a Rust client against an arbitrary third-party or internal API: use OpenAPI Generator's rust generator with the reqwest library. It's broadly tested, actively released (monthly-ish cadence, v7.25.0 as of late August 2026), and doesn't assume anything about how your spec was produced.
Reach for progenitor instead if your API is Dropshot-based, or you're willing to accept some friction in exchange for output that reads more like hand-written Rust. Skip paperclip as a new default for now — it says so itself.
Whichever generator you pick, the spec quality rules are the same as every other language: every operation needs an operationId, schemas belong in components/schemas, and security schemes need to be defined — see OpenAPI best practices for SDK-friendly specs, or run Sourced's OpenAPI validator to catch spec problems before any of these three tools sees the file.
Where Sourced fits (and doesn't)
Plainly: Sourced's generated SDKs focus on TypeScript and Python today — the two ecosystems where teams publish first. If Rust is your target, generate it with OpenAPI Generator or progenitor above, and bring Sourced in for the part of the workflow it does own: docs, llms.txt, and validation on the same spec.
What carries over regardless of which language generator you use, from the same spec:
- Hosted docs, free to try, generated from your OpenAPI spec with a private preview URL.
llms.txtgeneration for LLM-agent-readable API docs — llms-txt generator.- OpenAPI validation that catches spec issues before any generator (Rust, PHP, or otherwise) produces bad output — openapi-validator.
- Spec diffing across versions, so you catch breaking changes before your Rust client does — openapi-diff.
Generate your Rust SDK with the right OSS tool for your case; give the same spec to Sourced for free hosted docs, llms.txt, and validation in one pass. Create hosted docs from your repo or start free — unlimited previews, up to 2 hosted noindex docs review sites and one hosted MCP server, no credit card.
Generating SDKs in other languages
Same spec, different target language — see TypeScript, Python, PHP, Kotlin, Swift, Go, Java, C#, and Ruby.
FAQ
Does Sourced generate Rust SDKs?
No — see "Where Sourced fits" above for what Sourced covers instead. For Rust, use OpenAPI Generator's rust generator or progenitor, both covered above.
Which Rust HTTP client library should I pick in OpenAPI Generator?
reqwest is the default and the most widely used async HTTP client in the Rust ecosystem — start there. reqwest-trait adds a trait-based interface useful for mocking with mockall. hyper/hyper0x are lower-level options if you need direct Hyper integration.
Is progenitor only for Dropshot APIs?
progenitor works best against specs produced by Dropshot, Oxide's Rust web framework, and that's the primary case its maintainers test against. It can generate clients for other specs too, but its own documentation warns it "may fail for some OpenAPI documents" outside that target case — test against your spec before adopting it in CI.
Is paperclip safe to use in production as of September 2026?
paperclip's own README says it "may not be ready for production use just yet," and its last release (v0.9.7) was in April 2026 — several months stale relative to progenitor and OpenAPI Generator. Use it only if you're already committed to it for server-side codegen.
Does OpenAPI 3.1 work with these generators?
OpenAPI Generator has broad 3.1 support across its generators, including rust. Check progenitor's current release notes for your specific spec's constructs before relying on it for 3.1-specific features — it's a smaller, more targeted project than OpenAPI Generator.
Can I use Sourced for Rust docs even though Sourced's SDK generation stops at TypeScript and Python?
Yes. Sourced's hosted docs, llms.txt, and validator all work from your OpenAPI spec directly, independent of which language's SDK you generate from that same spec.