SDK generation
Generate SDKs from OpenAPI, then verify them with their language toolchains.
Doctorine turns one canonical OpenAPI graph into verified TypeScript, Python, and Go SDK artifacts. Each target combines a reviewed, language-specific runtime kernel with the resource and model code derived from your contract.
Resolved input
bundleSha + configSha
Verified output
files + sdkSha + verdict
The generator is only useful if the output survives real checks
An OpenAPI SDK generator can create a large file tree and still leave a team with broken types, awkward request methods, or runtime behavior that does not fit the language. Doctorine separates stable runtime concerns from contract-shaped code. The transport and behavior live in reviewed kernels; operations and models are resolved from the canonical graph.
Generation and verification are one job. TypeScript, Python, and Go targets run their strict toolchains before Doctorine reports a verified result. A failure stays visible with diagnostics. This makes “generated” a factual state and “verified” a separate, stronger state.
Configuration is part of the evidence. Naming, package shape, authentication mapping, pagination, and other resolved choices feed the artifact identity alongside the canonical graph and generator versions. A reviewer can therefore distinguish a real input change from an unexplained difference in emitted files. The same resolved configuration also lets local CLI output and factory output be compared without inventing a second generation engine.
Supported SDK targets
Doctorine deliberately supports a compact target set today. Each language has its own runtime design and verification path instead of inheriting a generic template unchanged.
-
TypeScript
Typed resources, models, errors, pagination, and a hand-written runtime kernel.
Verification: Strict TypeScript compilation
-
Python
Synchronous and asynchronous client paths over a language-specific runtime kernel.
Verification: Ruff, strict mypy, and generated smoke coverage
-
Go
Idiomatic packages and typed errors with a Go-specific transport layer.
Verification: Formatting, vetting, static analysis, and generated tests
Quality model
Four checks between a schema and an SDK release
-
Contract fidelity
Operation fingerprints keep generated methods and examples attached to the correct API operation as names and files move.
-
Language-native runtime
Transport, authentication, retries, pagination, streaming, and error behavior live in reviewed kernels instead of being improvised for every endpoint.
-
Strict verification
A target that fails its language toolchain is a failed build. It is not marked as a generated artifact ready for release.
-
Reproducible identity
The contract, resolved configuration, generator version, and kernel version contribute to the SDK artifact identity.
Keep the SDK beside the portal and agent surface
SDK generation is not a detached export job. The same canonical operation identities can drive portal reference and code samples, then inform a future MCP package. That shared model gives reviewers a practical question to answer: does this release describe and invoke the same API everywhere?
When a contract changes, the affected artifacts can be regenerated from known inputs. An unchanged artifact identity becomes a no-op rather than a new, unexplained build. This is useful for supply-chain review and also reduces ordinary release uncertainty.
Teams still own release policy. A verified file map tells you that the supported target passed its checks for these inputs; it does not decide versioning, compatibility promises, repository approval, or when downstream developers should upgrade.
Artifact interpretation
Read provenance and verification as separate evidence
Provenance answers which inputs and tool versions produced a file map. Verification answers whether that target passed its configured compiler, linter, static analysis, and generated tests. A release review needs both. A stable hash cannot prove code quality, while a green compiler result without recorded inputs cannot explain why two builds differ.
Start a proof of concept with an API that includes authentication, pagination, structured errors, optional fields, and at least one awkward schema edge. Compare generated method names and examples with the portal, inspect diagnostics from a deliberate failure, and regenerate from identical inputs. That test exercises the workflow a production contract will stress.
- bundleSha
- The canonical OpenAPI bundle that supplied the operation and model graph.
- configSha
- The resolved naming, package, authentication, and generation choices.
- generator + kernel
- The emitter and reviewed language-runtime versions used for the build.
- sdkSha
- The identity of the resulting generated file map, not a registry publication receipt.
Generation failures should remain visible
Common failures include ambiguous operation identities, schema constructs the target cannot represent safely, conflicting package names, unsupported authentication mapping, and emitted code that fails a strict toolchain. Suppressing those diagnostics creates a convincing but unusable download. Doctorine keeps the build failed until the target verifies, so teams can fix the contract or configuration rather than hand-edit generated output that will drift next time.
What Doctorine can prove
Product claims reviewed by Doctorine engineering.
TypeScript, Python, and Go emitters exist as live targets, and the SDK factory has an end-to-end production receipt. Generated artifacts carry deterministic identities and strict verification results. The Doctorine CLI resolves the same configuration and emitters, preserving local and factory parity for the supported targets.
Generate from the contract you already maintain.
Import an OpenAPI spec, choose a supported language, and inspect both the files and verification result.
Generate an SDK