Skip to main content
Doctorine
Menu

Developer portals

Publish a developer portal that shares its source with supported client surfaces.

A developer portal should do more than render attractive API documentation. Doctorine combines authored guides with contract-derived reference, then releases the result from the same canonical graph used for SDK artifacts and agent-readable context.

Source

Guides + OpenAPI

Build

Canonical portal bundle

Release

Preview → activate → roll back

The portal is the integration path, not a document archive

Developers arrive with a task: authenticate, make a first request, handle an error, or ship an integration. A useful API portal connects that task to accurate reference and executable client material. It should make the next decision obvious without forcing the reader to reconcile an API reference, a README, and an SDK repository by hand.

Doctorine treats portal publication as part of API delivery. Writers can explain workflows in guides, while the contract supplies operation structure. The published bundle is immutable, so reviewers can inspect the exact candidate before activation and return to a prior release if the current one is wrong.

Four layers of a dependable developer portal

A schema is necessary, but it is not sufficient. Portal quality comes from keeping authored context and generated truth in one release process, with evidence for what was built.

  1. Layer 1

    Guides that explain the workflow

    Write onboarding, authentication, errors, and use-case guidance around the API reference. Guides carry the decisions a schema cannot express.

  2. Layer 2

    Reference derived from OpenAPI

    Paths, operations, parameters, request bodies, responses, and security requirements come from the canonical API graph instead of a second manual inventory.

  3. Layer 3

    Examples that keep the same identity

    Code samples stay attached to the operation they demonstrate, making it easier to review whether the portal and generated clients tell the same story.

  4. Layer 4

    A release teams can inspect

    Preview an immutable build, check its content address, activate it, and retain a reversible path when a release needs to move back.

From contract change to portal release

Import the changed OpenAPI file or URL, review validation diagnostics, and compile the canonical graph. Add or update the guide that explains the user-facing consequence. A preview then shows the combined reference and authored content as one candidate release.

Activation changes which immutable release is served; it does not rewrite the previous build. That distinction gives teams a practical rollback path. Source-controlled workflows are supported by Doctorine's deterministic content model, but fully self-serve GitHub connection for an unfamiliar customer remains a qualified capability rather than a finished promise.

Active release identity

Contract
Canonical bundle hash
Portal
Content-addressed build
Activation
Reversible release pointer

Choose the portal around its audience

  • Public API portal

    Customer-facing APIs where discovery and self-serve onboarding matter.

    Eligible public portals can publish llms.txt and llms-full.txt alongside human-readable docs.

    Explore public api portal

  • Partner API portal

    Controlled integrations where named partners need current instructions and artifacts.

    Private portal bytes can be gated at the edge. Enterprise SSO and SCIM are not current claims.

    Explore partner api portal

  • Internal API portal

    Product and platform teams that want consistent private consumption surfaces.

    Doctorine complements a service catalog; it is not a Backstage-style ownership or infrastructure catalog.

    Explore internal api portal

Buyer rubric

Evaluate a portal with developer tasks and release evidence

Use one real endpoint rather than a polished demo project. Ask someone unfamiliar with the API to locate credentials, form a valid request, choose a supported client, understand an error, and identify the current version. Then change one contract field and follow it through reference, examples, and release review. The result shows whether the portal shortens integration work or only changes where documentation is displayed.

  • Task completion

    Can a new developer find authentication, make a first request, interpret the response, and recover from a likely error without opening another system?

  • Contract fidelity

    Do paths, parameters, request bodies, response shapes, security requirements, and examples trace back to the accepted OpenAPI contract?

  • Release safety

    Can a reviewer inspect the exact candidate, identify its inputs, activate it deliberately, and restore the previous immutable release?

  • Audience boundary

    Does public, partner, or internal delivery enforce the intended access boundary before any private bytes are returned?

Failure modes to test before migration

Attractive reference pages still fail when authentication is buried, examples describe an old request shape, guide links lead away from the operation, or a deploy silently replaces the only known-good version. Private portals fail more seriously when access is checked after content is returned. Include these cases in acceptance review, alongside a broken schema import and a deliberately failed release, so the team sees diagnostics and recovery rather than only success.

What Doctorine can prove

Product claims reviewed by Doctorine engineering.

Doctorine ships hosted, branded portals built from guides and OpenAPI. Published releases are immutable and activation is reversible. Public portals can expose entitled llms.txt files, and private portal bytes can be gated at the edge. These are present-tense capabilities, not roadmap labels.

See how the same graph produces verified SDKs

Build the portal from a real contract.

Import an OpenAPI spec, add the guidance developers need, and inspect the release before it becomes public or private.

Import your OpenAPI spec