Public API delivery
Build a customer API portal from the contract your customers call.
Doctorine helps customer API teams publish a developer portal, consistent examples, verified TypeScript, Python, and Go SDK artifacts, and agent-readable outputs from one canonical OpenAPI graph.
01
Discover
02
Understand
03
Integrate
04
Ship
Public API documentation is part of the product
A public endpoint may be technically available while still being difficult to adopt. Customers have to discover the right operation, understand authentication, assemble a valid request, read failures, and decide whether to write raw HTTP or use a client. Every inconsistent surface adds another place where that path can break.
Doctorine starts from the OpenAPI contract your team accepts for the release. It compiles one canonical graph and carries its operations into the portal, examples, supported SDK artifacts, and agent surfaces. Authored guides still explain customer intent. The contract supplies the structured truth that should not be copied into several tools.
Find onboarding breaks before customers do
Treat launch review as a customer journey, not a count of published pages. Give a reviewer who did not build the API a plausible goal and only the portal entry URL. Record every point where the reviewer needs private context, guesses a value, switches to chat, or finds a client example that disagrees with the reference. Those handoffs reveal more than checking whether each page exists.
-
Reference without a first task
Look for: Developers can inspect operations but cannot tell which request proves the product works for them.
Release response: Name one useful outcome, provide the smallest valid request, and link every prerequisite before the reference.
-
Authentication explained too late
Look for: A developer reaches a request example before knowing how to obtain credentials or select an environment.
Release response: Put credential setup, base URL, scopes, and a safe test path in the quickstart, then repeat only operation-specific rules.
-
Client code drifts from the contract
Look for: A copied snippet or SDK method uses names and types that no longer match the active API release.
Release response: Review examples and supported SDK artifacts against the same canonical graph and release candidate before activation.
-
A breaking change has no owner
Look for: Reference updates reach production without a dated migration note, support route, or rollback decision.
Release response: Assign an API product owner to the change narrative and an engineering owner to contract and artifact verification.
Doctorine can keep contract-derived reference and supported SDK output coherent, but it cannot decide the customer job, issue API credentials, or write a breaking-change policy for the team. Keep those owners visible in the release checklist. First-successful-call instrumentation remains beta until its production accuracy receipt is complete, so combine product signals with direct onboarding review instead of presenting an unverified adoption number.
Design the customer path around decisions
A long reference page is not an onboarding strategy. Give each stage an explicit answer and connect it to the next useful action.
-
Find the right operation
Use clear navigation and authored task guides to connect a product goal to the contract-derived API reference.
-
Understand the request
Keep parameters, request bodies, security requirements, examples, and response shapes attached to the same operation.
-
Choose a client surface
Offer consistent code samples and verified TypeScript, Python, or Go SDK artifacts instead of parallel hand-maintained snippets.
-
Recover from failure
Explain error handling in guides while the contract and SDK types preserve the structured response model.
Release core customer surfaces from known inputs
Doctorine validates an imported file or URL and compiles the canonical API graph. A portal preview combines generated reference with authored guides. Supported SDK targets produce their own artifact identities and strict verification results. The active portal release is immutable, making the preview reproducible and activation reversible.
Eligible public portals also publish llms.txt and llms-full.txt. A
customer-accessible MCP generation path is still held. The published text files are concrete
machine-readable surfaces; they do not imply API invocation or control over external agents.
Keep customer communication beside the generated evidence. A contract can show that a field changed; a release note must explain when the change takes effect, who is affected, and what an existing integration should do next.
Public API launch checklist
- A maintained OpenAPI contract with stable operation identities.
- A quickstart that names authentication, environment, and the first useful request.
- Task guides for the two or three customer jobs that drive product value.
- Reference, examples, and SDK methods reviewed against one release candidate.
- A public changelog and a rollback path for a bad documentation release.
- A clear support route when contract truth does not answer the integration question.
Keep the portal, SDK, and agent path connected
A customer should not find one parameter name in the reference, another in a code sample, and a third in an agent tool. Sharing operation identity does not replace editorial review, but it gives that review one dependable frame. Teams can inspect which output came from which contract and whether its verification passed.
What Doctorine can prove
Product claims reviewed by Doctorine engineering.
Doctorine ships file and URL OpenAPI import, canonical compilation, hosted branded portals,
immutable releases, reversible activation, verified TypeScript, Python, and Go SDK artifacts,
and public-portal llms.txt output. These capabilities share the same API graph.
Start with the API your customers call.
Import its OpenAPI contract and inspect the portal and SDK candidates alongside agent-readable context from the same graph.
Import your public API