Doctorine field manuals
Build the path from API contract to first call.
These guides are for API product, DevEx, platform, and documentation teams that need more than publishing advice. Each resource gives you a workflow, an evaluation method, explicit failure modes, and a clear boundary between an API contract and the developer surfaces built from it.
Start here
Four guides, four different decisions
The guides share one operating principle: an API document is useful only when it helps a developer make a correct request. Choose the decision in front of you instead of reading a generic documentation playbook from end to end.
-
API lifecycle management
API Delivery vs API Management: Where Each Fits in the API Lifecycle
API management governs runtime traffic and policy. API delivery turns a contract into docs, SDKs, examples, and agent tools. Learn where each belongs.
Standards-linked lifecycle boundaries and a claims-audited Doctorine capability map.
Read api delivery vs api management: where each fits in the api lifecycle -
Workflow guide
Docs as Code: A Workflow That Prevents API Drift
Use this docs-as-code workflow to review prose, OpenAPI, examples, generated reference, and release evidence together without creating a second source of truth.
Includes a seven-stage workflow, pull-request checklist, ownership map, and failure-mode review.
Read docs as code: a workflow that prevents api drift -
Protocol guide
OpenAPI to MCP: Build Safe, Useful Agent Tools
A practical OpenAPI-to-MCP workflow for operation selection, tool schemas, descriptions, authorization, side effects, testing, and release verification.
Includes a worked operation mapping, release checklist, security boundaries, and verification matrix.
Read openapi to mcp: build safe, useful agent tools -
Evaluation guide
API Documentation Examples: A Practical Evaluation
Evaluate API documentation examples with a first-call rubric covering orientation, authentication, requests, responses, errors, operations, and change safety.
Includes annotated patterns, an evidence-based scorecard, and a review exercise your team can reuse.
Read api documentation examples: a practical evaluation
From learning to delivery
Follow the question, not the feature list
Educational pages should lead to the product surface that puts the method into practice. These routes connect each research question to a concrete delivery decision.
- See the API delivery platform
How should we publish the complete API experience?
Start with the API delivery platform and inspect the portal, SDK, and agent output model.
- Plan a developer portal
How should developers discover and learn the API?
Review the developer-portal workflow, including public and private delivery boundaries.
- Review SDK generation
How do generated clients stay trustworthy?
Inspect the supported language targets, strict verification, and artifact provenance.
- Review agent-ready API outputs
How should an API serve coding agents?
Separate machine-readable context from executable tools and make the authorization boundary explicit.
What every Doctorine resource includes
We publish fewer pages and ask more of each one. A guide must answer the question early, show the work, name the cases that fail, link standards claims to primary sources, and say where Doctorine is not the right tool. Product behavior is reviewed against the current claims ledger rather than inferred from a roadmap.
- Accountability
- Every guide carries a maintainer, technical review owner, and last-tested date.
- Boundaries
- Unsupported protocols, authentication gaps, and manual work are stated where they matter.
- Usable evidence
- Checklists, worked examples, and verification steps replace decorative summaries.
- A release path
- Internal links connect the method to a product surface and a concrete next action.
Test the workflow with your own contract.
Import an OpenAPI spec and inspect the portal, SDK, and agent-readable context derived from the same canonical graph.
Import an OpenAPI spec