Three tools generate a working Go SDK from an OpenAPI spec in 2026: oapi-codegen, ogen, and OpenAPI Generator's go target. For most teams, oapi-codegen is the right default — Go-idiomatic output, actively maintained under its own GitHub org, and one YAML config drives both client and server generation. Sourced doesn't generate a Go SDK; pair your spec with one of the three tools above, and use Sourced for the spec-level work all three depend on — validation, hosted docs, and llms.txt — for free.
The three real options
oapi-codegen — the Go-native default
oapi-codegen moved to its own GitHub organization in May 2024 and is on major version 2, with the import path github.com/oapi-codegen/oapi-codegen/v2. It's actively developed — over a thousand commits on main — and is the tool most Go teams reach for first because it produces plain Go structs and interfaces instead of a Java-generator's idea of what Go should look like. It can generate a client, a server (chi, echo, gin, stdlib), or both from the same spec.
Install it as a Go tool dependency:
go get -tool github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest
Or as a standalone binary:
go install github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest
Configuration is a YAML file, not command-line flags:
# cfg.yaml
package: api
output: api.gen.go
generate:
models: true
client: true
Generate with:
oapi-codegen -config cfg.yaml ./openapi.yaml
Most teams wire this into a //go:generate directive so go generate ./... regenerates the client whenever the spec changes.
ogen — for a fully static, reflection-free client
ogen takes a stricter approach: it generates statically-typed Go with no interface{} and no runtime reflection, trading some flexibility for compile-time safety and speed. It's a large, active project (thousands of commits) marked stable by its maintainers, and it's a solid pick when you're generating a client only (it doesn't do server-side chi/echo-style routers the way oapi-codegen does) and want the tightest possible typing.
go install -v github.com/ogen-go/ogen/cmd/ogen@latest
Docker works too, if you'd rather not add it to your Go toolchain:
docker run --rm --volume ".:/workspace" ghcr.io/ogen-go/ogen:latest --target /workspace/out -package api --clean /workspace/openapi.json
Direct CLI generation:
ogen --target ./out -package api --clean ./openapi.json
OpenAPI Generator — the multi-language option
OpenAPI Generator is the Java-based generator that supports dozens of languages from one config format, currently at version 7.25.0 (as of September 2026, per its installation docs). Its go generator produces working code, but it reads like output from a tool designed for Java first — naming conventions and package layout feel less native than oapi-codegen or ogen. It earns its place when your org already standardizes on OpenAPI Generator for Java, C#, Ruby, or other languages and wants one config format everywhere rather than the best tool per language.
# npm
npx @openapitools/openapi-generator-cli generate -i openapi.yaml -g go -o ./generated
# Docker
docker run --rm -v "${PWD}:/local" openapitools/openapi-generator-cli generate \
-i /local/openapi.yaml -g go -o /local/out/go
# Homebrew (macOS)
brew install openapi-generator
openapi-generator generate -i openapi.yaml -g go -o ./generated
Comparison
| Tool | Output | Server support | Status (Sep 2026) | Install | Best for |
|---|---|---|---|---|---|
| oapi-codegen | Idiomatic Go structs + client/server | Yes (chi, echo, gin, stdlib) | Active, own org since May 2024 | go install .../v2/cmd/oapi-codegen |
Default choice for Go teams |
| ogen | Fully static, no reflection | No (client-focused) | Active, marked stable | go install .../cmd/ogen |
Strict typing, client-only |
OpenAPI Generator (go) |
Generic client, Java-flavored | No | Active (v7.25.0, Aug 2026) | npm / brew / Docker / jar | Org already standardized on it |
A minimal working sequence
Using oapi-codegen end to end:
go install github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest
cat > cfg.yaml <<'EOF'
package: api
output: api.gen.go
generate:
models: true
client: true
EOF
oapi-codegen -config cfg.yaml ./openapi.yaml
go build ./...
That's a working typed client package in three commands, assuming your spec has operationId on every operation — the generated method name comes straight from it.
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 Go is your target, generate it with oapi-codegen (or ogen, or OpenAPI Generator) directly, and bring Sourced in for the part of the workflow it does own: docs, llms.txt, and validation on the same spec.
Where Sourced is useful regardless of which language generator you use: it takes the same OpenAPI spec and produces hosted API docs, an llms.txt file for LLM-based tooling, and spec validation — all language-independent, all free to try. Generate your Go SDK with oapi-codegen, then hand the same spec to Sourced for docs and validation in a second, unrelated pass. Run the spec through the OpenAPI validator first; a spec issue that breaks oapi-codegen's codegen will break your docs too.
FAQ
Which Go SDK generator should I use by default?
oapi-codegen, for most teams. It's Go-idiomatic, actively maintained, and can generate both client and server code from the same config — useful if you also own the API implementation, not just the SDK.
Is oapi-codegen still maintained?
Yes, as of September 2026. It moved to its own GitHub organization (oapi-codegen/oapi-codegen) in May 2024 and is on major version 2 (.../v2 import path), with regular commits on main.
When should I use ogen instead of oapi-codegen?
When you want a client with zero reflection and zero interface{} in the generated code — ogen trades some flexibility for stricter static typing. It doesn't generate server-side routers, so skip it if you need those.
Does OpenAPI Generator's Go output look like hand-written Go?
Not quite — its naming conventions and structure read as generated-from-a-generic-template rather than Go-native, compared to oapi-codegen or ogen. It's still a solid fallback if your org already runs OpenAPI Generator for other languages and wants one config format.
Does Sourced generate Go SDKs?
No — see "Honest scope" above for what Sourced covers instead. Use one of the tools above for the Go client.
My spec has no operationId on half the endpoints — will that break Go codegen?
It won't break the build, but you'll get ugly generated method names (something like PostUsersUsers). Add operationId to every operation before generating; see OpenAPI best practices for SDK-friendly specs for the full list of spec-hygiene issues that hurt every generator, Go included.
Get hosted docs and llms.txt from the same spec
Whichever Go generator you pick, 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, and the shortest path from OpenAPI spec to live docs and SDK previews (the counted-steps walkthrough). Validate the spec first with the OpenAPI validator, and if you need typed SDKs too, see the TypeScript and Python generation guides — the two languages Sourced generates directly.