Ruby's OpenAPI codegen ecosystem is thin: as of September 2026, OpenAPI Generator's ruby target is the only actively-used, production-grade option. There's no Ruby equivalent of Go's oapi-codegen or Python's openapi-python-client — a modern, Ruby-native generator built and maintained specifically for the language. Microsoft's Kiota lists Ruby as a preview-maturity target, not yet recommended for production. If Ruby is your only SDK target, OpenAPI Generator is the answer; hand-writing a thin Faraday wrapper is a reasonable alternative for small APIs. Sourced doesn't generate a Ruby SDK — use OpenAPI Generator's ruby target above, and see "Honest scope" below for what Sourced does cover.
The one real option: OpenAPI Generator's ruby target
OpenAPI Generator's ruby generator is marked stable in the project's own docs and supports three HTTP library backends via the library option, per its generator reference: faraday (the default, Faraday >= 1.0.1), httpx (a newer async-capable option, HTTPX >= 1.0.0), and typhoeus (Typhoeus >= 1.0.1, built for concurrent requests).
# npm wrapper
npx @openapitools/openapi-generator-cli generate -i openapi.yaml -g ruby -o ./generated \
-p gemName=my_api_client
# Homebrew (macOS)
brew install openapi-generator
openapi-generator generate -i openapi.yaml -g ruby -o ./generated -p gemName=my_api_client
# Docker
docker run --rm -v "${PWD}:/local" openapitools/openapi-generator-cli generate \
-i /local/openapi.yaml -g ruby -o /local/out -p gemName=my_api_client
To pick a different HTTP backend, pass library:
openapi-generator generate -i openapi.yaml -g ruby -o ./generated \
-p gemName=my_api_client --library typhoeus
Generated gems follow standard Ruby conventions — snake_case gem name, a top-level module matching it in CamelCase, and a .gemspec you can gem build and push to RubyGems or a private gem server.
Why the ecosystem is this thin
Every other language in this series has a language-native alternative to OpenAPI Generator: Go has oapi-codegen and ogen, Python has openapi-python-client, and C#/Java both have Microsoft- or community-built generators outside the OpenAPI Generator project. Ruby doesn't currently have an equivalent — no actively-maintained, Ruby-first OpenAPI codegen tool has reached the adoption level of those projects as of September 2026.
Kiota, Microsoft's cross-language generator (covered in the Go, Java, and C# posts in this series), does support Ruby, but its own supported-languages table marks Ruby generation and its HTTP layer as preview, not stable — the tier below the one C#, Go, Java, PHP, and Python sit at. The table also shows Ruby's serialization support as JSON-only; form, multipart, and plain-text serialization are listed as not yet implemented, and — unlike every other supported language — there's no published quickstart guide linked for Ruby. Treat Kiota Ruby as something to watch, not something to ship on top of, until that changes.
That leaves two practical paths for Ruby: OpenAPI Generator's ruby target, or hand-writing a thin client.
Hand-written Ruby client (small APIs only)
For ten endpoints or fewer, a hand-written wrapper around Faraday or Net::HTTP is often less friction than debugging generator output you didn't write:
require "faraday"
require "json"
class ApiError < StandardError
attr_reader :status, :body
def initialize(status, body)
@status = status
@body = body
super("API #{status}: #{body}")
end
end
class Client
def initialize(api_key:, base_url: "https://api.example.com")
@conn = Faraday.new(url: base_url) do |f|
f.headers["Authorization"] = "Bearer #{api_key}"
f.headers["Content-Type"] = "application/json"
end
end
def list_users
res = @conn.get("/users")
raise ApiError.new(res.status, res.body) unless res.success?
JSON.parse(res.body)
end
end
This doesn't scale past a handful of endpoints — the moment the spec changes, nothing tells you the client drifted. That drift risk is exactly what pushes most teams with more than ten or so endpoints toward OpenAPI Generator instead.
Comparison
| Option | Maturity (Sep 2026) | HTTP backends | Best for |
|---|---|---|---|
OpenAPI Generator (ruby) |
Stable, actively maintained | Faraday (default), HTTPX, Typhoeus | The practical default for any Ruby SDK generation |
| Kiota (Ruby target) | Preview — not production-recommended | Kiota HTTP (Faraday-independent) | Watching, not shipping, as of Sep 2026 |
| Hand-written client | N/A | Your choice (Faraday, Net::HTTP) | Ten endpoints or fewer, full control |
A minimal working sequence
npx @openapitools/openapi-generator-cli generate \
-i ./openapi.yaml -g ruby -o ./generated \
-p gemName=my_api_client,moduleName=MyApiClient
cd generated && bundle install && rspec
That produces a gem skeleton with generated model classes, an API client class per tag, and a generated test suite scaffold — run bundle install to pull in Faraday and its dependencies before running the tests.
Honest scope: what Sourced does and doesn't do here
Sourced's generated SDKs focus on TypeScript and Python today — the two ecosystems where teams publish first. If Ruby is what your customers need, generate it with OpenAPI Generator's ruby target (or a hand-written client for a small API), and bring Sourced in for the part of the workflow it does own: docs, llms.txt, and validation on the same spec.
Where Sourced still helps on a Ruby-only project: the same OpenAPI spec that drives OpenAPI Generator's ruby output also drives hosted API docs, an llms.txt file, and spec validation — free, and none of it cares what language your SDK ends up in. Run the spec through the OpenAPI validator before codegen; Ruby's generator is as sensitive to missing operationIds and inlined schemas as any other target.
FAQ
What's the best tool to generate a Ruby SDK from OpenAPI?
OpenAPI Generator's ruby target, as of September 2026. It's the only actively-used, stable-maturity option — there's no Ruby-native equivalent of Go's oapi-codegen or Python's openapi-python-client yet.
Is Kiota a good option for Ruby?
Not yet for production. Kiota's own supported-languages table marks Ruby as preview maturity, with only JSON serialization implemented (form, multipart, and text are not) and no published Ruby quickstart. It's worth tracking, not adopting, until it reaches the same stable tier as Kiota's C#, Go, Java, or Python targets.
Which HTTP library should I pick for OpenAPI Generator's Ruby output?
Faraday, the default, unless you have a specific reason not to — it's the most widely used Ruby HTTP client and the best-supported option in the generator. Typhoeus is worth considering if you need concurrent/parallel requests; HTTPX is the newer async-capable option.
Should I just hand-write a Ruby client instead?
For ten endpoints or fewer, yes — it's often less work than adapting to generated code you didn't write. Past that, a hand-written client drifts silently every time the spec changes, and OpenAPI Generator's output at least stays in sync when you regenerate it.
Does Sourced generate Ruby SDKs?
No — see "Honest scope" above for what Sourced covers instead. Use OpenAPI Generator's ruby target for the SDK itself.
Will a bad spec break Ruby codegen the same way it breaks other languages?
Yes — missing operationId produces ugly generated method names, inline schemas produce anonymous nested model classes instead of reusable ones, and missing securitySchemes means no generated auth helper. None of this is Ruby-specific; see OpenAPI best practices for SDK-friendly specs for the full list before you generate.
Get hosted docs and llms.txt from the same spec
Whether you generate with OpenAPI Generator or hand-write your Ruby client, create hosted docs from your repo or start free with a direct OpenAPI upload — unlimited previews, up to 2 hosted noindex docs review sites and one hosted MCP server, no credit card. Validate the spec first with the OpenAPI validator, and if TypeScript or Python are also on your SDK list, see the TypeScript and Python generation guides — the two languages Sourced generates directly.