Use caseUpdated Jul 23, 2026

Publish private OpenAPI docs without launching a developer portal.

internalpage renders OpenAPI specs as private read-only references with ReDoc, Swagger UI, or Scalar, so product, QA, support, and engineering teammates can review internal APIs without making the docs public.

Start free Read docs

Upload OpenAPI YAML or JSON

Choose ReDoc, Swagger UI, or Scalar

Protect private API docs with Google sign-in

Update API references from CI or local scripts

OpenAPI publishing workflow

Deploy the docs. Control who can open them.

Publish an existing OpenAPI file to one stable URL, then protect the reference with Google sign-in.

Private API documentation

01Where should the API docs be deployed?

02How should access be controlled?

billing-api.openapi.yaml

openapi: 3.1.0
info:
  title: Billing API
  version: 1.4.0
paths:
  /invoices:
    get:
      summary: List invoices

ipinternalpage

publish ./openapi.yaml

Publishedinternalpage.com/w/acme/p/billing-api

AccessWorkspace + selected emails

internalpage.com/w/acme/p/billing-api

v1.4.0

Billing API

Private

Internal reference for billing services.

GET/invoices

GET/customers/{id}

Workspace access granted Other accounts denied

API docs deployed.Access controlled.

Why internal OpenAPI specs are hard to distribute

Many teams already generate OpenAPI specs, but the output stays in a repository, CI artifact, or Slack thread. Public developer portals are too visible for pre-release and service-to-service APIs, while a full portal adds ownership before the team needs onboarding, API keys, or interactive requests.

Internal services need readable docs before public release
QA and PM teammates need a browser link, not a raw YAML file
Specs change often enough that manual uploads become stale

Turn the spec into a private API reference

Upload an OpenAPI 3.x or Swagger 2.0 file and internalpage serves a private read-only viewer at a stable page URL. Teammates browse endpoints and schemas in the browser instead of downloading YAML, while the uploaded source remains the version behind the page.

Good for internal service APIs and pre-release partner specs
Keeps docs read-only by design
Works with CLI automation after CI generates the spec

Publish the API reference

npx @internalpage/cli publish ./openapi.yaml --slug specs/billing-api

Choose the renderer that fits the audience

ReDoc is the initial workspace default. Workspace owners can switch that default to Swagger UI or Scalar, and each OpenAPI page can either follow the workspace setting or keep its own override. Because the original spec remains the page source, changing the renderer does not require another upload.

Use the workspace default for a consistent documentation style
Override one page when its audience prefers a different layout
Let inherited pages follow later workspace default changes
Keep every renderer read-only without request execution

Choose an access scope that matches the API

Use workspace access for references every teammate may open, or selected-email grants for a pre-release integration, client handoff, or narrower security review. Test the viewer URL with an unauthorized account before sharing a sensitive reference.

Workspace access for broadly used internal services
Selected emails for client, partner, or limited review
Separate pages when specs need different audiences

Authentication protects delivery of the reference. Remove real credentials, example secrets, and sensitive server URLs from the OpenAPI source before publishing.

Keep the reference synchronized from CI

Generate or validate the OpenAPI file in CI, then publish to the same slug after a successful build. The viewer URL remains stable, so links in tickets, runbooks, and Slack do not need to change with every schema update.

Store the internalpage token in the CI secret store
Publish only after schema generation and validation succeed
Use one stable slug per API and lifecycle

Publish non-interactively

npx @internalpage/cli publish ./openapi.yaml --slug specs/billing-api --json

A practical review checklist

Before treating the page as the current source of truth, verify the title, version, servers, authentication schemes, schemas, and examples. Then check that the intended account can open it and an unrelated account cannot.

Confirm info.title and the displayed API version
Check endpoint grouping, request schemas, and error examples
Remove obsolete servers and placeholder credentials
Republish after every contract change that consumers must see

Know when you need a full developer portal

internalpage is a private, read-only API reference rather than a complete developer portal. Move to a broader portal when consumers need API key issuance, interactive requests, SDK generation, onboarding journeys, or public search and discovery.

Use internalpage for private browsing, review, and handoff
Keep production API credentials out of documentation
Add a larger portal only when operational requirements justify it

FAQ

Common questions

Which OpenAPI renderers does internalpage support?

ReDoc, Swagger UI, and Scalar are available in read-only mode. ReDoc is the initial workspace default, and individual pages can follow that default or use an override.

Can I keep API docs private to a Google Workspace domain?

Yes. Workspace-wide sharing lets signed-in colleagues open the private reference while outsiders are denied.

Can this replace a public developer portal?

No. It is better for internal and pre-release API references. Public API products usually need broader portal features such as onboarding, API keys, examples, and search.

Will publishing the same slug change the shared link?

No. Publishing a new valid spec to the same slug updates the page behind its existing viewer URL.