Facts and version numbers checked against the source repositories. Each page links the first-party documentation it summarises; where they disagree with a page here, they are the authority.
A spec goes in one end and SDKs come out the other. Knowing which stage you are in is what tells you where to fix something.
| Stage | Done by | Produces |
|---|---|---|
| Describe | your OpenAPI 3 or Swagger 2 spec | the API as its authors wrote it, paths and schemas |
| Model | apidef | entities, operations, fields and flows, with the guide that records why |
| Shape | you, editing the model | the SDK surface you actually want: names, types, which operations exist |
| Generate | sdkgen | one SDK per target language, plus a CLI, an MCP server and generated docs |
| Verify | the generated offline suites | tests that run with no server and no credentials |
The split matters when something is wrong. If the SDK exposes the wrong shape, the fix is in the model, and usually in apidef's guide. If the shape is right and the code is wrong, the fix is in a template or a component. Generated target code is never the place to fix either, because regeneration overwrites it.
Each is a separately published package with its own repository and its own release cycle. A sibling arriving later is a package, not a change to the generator.
Turns the model into SDKs. The generator. It reads the model apidef produced and writes one idiomatic SDK per target language, each with the same operation pipeline, the same feature set, generated documentation and an offline test suite.
Read the sdkgen documentationTurns a spec into a model. The front half. It reads an OpenAPI 3 or Swagger 2 spec and produces an internal model of entities, operations, fields and flows, inferring what the spec leaves implicit and recording why it decided each thing.
Read the apidef documentationScaffolds a project. The way in. One command turns an OpenAPI spec into a project with the model already built, the targets you asked for already added, and a generate script wired up. Start here unless you are working on the toolchain itself.
Read the create-sdkgen documentationGenerates documentation targets. An sdkgen package rather than a separate tool. sdkgen defines a docs kind, a target whose destination is a documentation system rather than a language; docgen supplies the items for it.
Not yet published. A repository exists and nothing is published from it. It is listed here so the shape of the toolchain is honest about what is real, and it will get a page when there is something to document.
apigen on GitHubEvery code sample in this section comes from one of these, so you can check it against the repository it came from rather than trusting it. They are picked to be complementary rather than redundant.
create-sdkgen.sdkgen.apidef.docgen, the worked example of a package.The toolchain is MIT and open, and the catalog holds 600+ generated SDKs readable without installing anything.