Skip to main content
Doctorine
Menu

API documentation platform

API documentation software that keeps portals, SDKs, and agent context aligned.

Doctorine is an OpenAPI-first API documentation tool that connects a hosted developer portal, verified SDK artifacts, and agent-readable context through one canonical graph. It helps teams ship a coherent developer experience without copying the same operation into separate systems.

Input

openapi.yaml

One validated API contract

Outputs

Portal · samples · SDKs · llms.txt

One set of operation identities and artifact hashes

API delivery starts after the endpoint works

API management handles concerns such as gateways, traffic policy, and runtime protection. General documentation tools help teams write and publish knowledge. Doctorine focuses on a narrower job: turning an approved OpenAPI contract into the interfaces a developer needs to understand and use that API.

That boundary matters. Doctorine does not replace your gateway, test suite, service catalog, or source repository. It carries contract truth into a portal, client artifacts, examples, and machine-readable agent surfaces. The result is a release path that can be reviewed as a whole instead of a collection of manually synchronized projects.

The output map

Three product surfaces, one operation model

A path, parameter, security requirement, or operation ID should not mean something different in the portal than it does in an SDK or future MCP tool. Doctorine derives shipped surfaces from one canonical graph so a release can be inspected for agreement.

  • Portal

    A hosted developer portal

    Publish guides, API reference, consistent code samples, and a branded navigation structure from the same canonical API graph.

    Explore a hosted developer portal

  • SDKs

    Verified client artifacts

    Generate TypeScript, Python, and Go SDK artifacts, then run strict language toolchains before a build can be called verified.

    Explore verified client artifacts

  • Agents

    Machine-readable API surfaces

    Publish llms.txt on entitled public portals and map future MCP tools without presenting the internal emitter as customer-accessible.

    Explore machine-readable api surfaces

A release workflow with identifiable outputs

Determinism is not the product category. It is the reason a team can trust the outputs. Doctorine records content-addressed releases and verification results so the same accepted input can be reproduced, reviewed, and rolled back without relying on an editor's memory.

  1. Import

    Bring in an OpenAPI document from a file or URL. Doctorine validates it and compiles one canonical graph.

  2. Inspect

    Review the hosted portal and SDK build candidates alongside agent-readable context against the same operation identities.

  3. Verify

    Build outputs with explicit diagnostics and content hashes. Failed verification remains visible instead of being marketed as success.

  4. Activate

    Activate an immutable portal release. Verified SDK artifacts keep their own identities, while MCP distribution stays outside the shipped path.

Built for teams that serve developers

A company does not need to sell an API as its only product to need disciplined API delivery. Customer, partner, and internal developers all encounter the same basic questions: what can I call, how do I authenticate, which client should I use, and what changed?

  • Customer API teams

    Give external developers a public onboarding path that keeps reference, examples, and client artifacts aligned.

    Plan a public API experience

  • Partner API teams

    Deliver controlled integration material to named partners without maintaining a second content system.

    Plan a partner API portal

  • Internal platform teams

    Apply the same contract discipline to private APIs while keeping service catalogs and runtime gateways in their proper roles.

    Plan internal API delivery

Evaluation guide

Test the operating model before comparing feature lists

A long checklist can hide the cost Doctorine is meant to remove: the same API operation being described, sampled, and packaged independently. Start with one representative contract change. Trace how it reaches every developer-facing output, which checks can stop a bad release, and what evidence survives after publication. That exercise exposes workflow gaps more reliably than a screenshot comparison.

Is OpenAPI the accepted contract?
Doctorine can expose contract changes consistently only when the source is maintained and reviewed. A stale schema simply reproduces stale truth faster.
Which outputs must agree?
List the portal reference, examples, SDK languages, and machine-readable files your developers actually use. The shared graph is valuable when it replaces real duplicate inventories.
What evidence does release review require?
Decide whether reviewers need a portal preview, immutable release identity, SDK file map, toolchain verdict, or rollback path before selecting the workflow.
Which system keeps runtime authority?
Your gateway, identity provider, service catalog, and observability stack retain their jobs. Doctorine should not become an accidental policy or runtime control plane.

Read a real artifact, not a feature claim

Doctorine's tracked TypeScript receipt records the canonical bundle, resolved configuration, intermediate representation, generator and kernel versions, target language, package identity, and final SDK hash. It is deliberately compact: the receipt proves provenance for one artifact; it does not claim registry publication, compatibility, or developer adoption.

Inspect the Doctorine SDK provenance receipt

What is shipped today

Product claims reviewed by Doctorine engineering.

  • File and URL OpenAPI import with validation and canonical compilation.
  • Hosted, branded portals with immutable releases and reversible activation.
  • Strictly verified TypeScript, Python, and Go SDK artifacts.
  • llms.txt and llms-full.txt on entitled public portals.
  • Private portal bytes gated at the edge.

Inspect what your contract can produce.

Import an OpenAPI spec and review the generated surfaces before you commit to a migration or rollout.

Import an OpenAPI spec