Share private API docs with clients and partners—without opening up the rest of your workspace.

External collaborators rarely need the same view as the engineering team. Decide which endpoints, schemas, environments, and examples belong in the handoff before choosing a hosting tool. This keeps the shared document useful without turning it into a copy of your internal API catalog.

• Create a partner-facing spec when the public contract differs from the internal one
• Include enough examples to complete the integration
• Leave out internal endpoints, incident notes, and experimental operations
• Use separate pages when clients receive different contract versions

Access control is the last gate, not the editing process. Review the exact YAML or JSON that will be published. Server URLs, examples, descriptions, and vendor extensions often reveal more than the endpoint list alone.

• Lint the final file and confirm its title and version
• Replace real tokens, credentials, and customer data with obvious placeholders
• Remove private hostnames and infrastructure notes the recipient does not need
• Resolve or deliberately retain external $ref files before the handoff

A private link limits who can open the page. It cannot make a secret embedded in the document harmless.

Use a slug that still makes sense six months from now. Publishing the next approved version to the same slug means onboarding notes, tickets, and email threads do not fill up with expired links.

• Keep the source file and review process in your existing repository
• Store the publishing token in CI secrets
• Share the viewer URL, never the publishing token
• Republish only after the external version has been reviewed

npx @internalpage/cli publish ./dist/partner-openapi.yaml --slug partners/acme-api

Add the Google accounts your client or partner will actually use. Named access is easier to revoke and audit than a password passed around a project channel, and it does not require making every viewer a member of your internal workspace.

• Confirm the exact account with the recipient before the first review
• Prefer individual identities over a shared team login
• Set an expiry date for a time-bounded implementation or security review
• Remove access when the project or relationship changes

An owner opening the page proves very little. Before sending the link, try it while signed out, with one invited account, and with one account that must be denied. Then republish once to confirm the destination remains stable.

A private read-only page is a good handoff for an API contract. Choose a full developer portal when the relationship also needs credential provisioning, interactive requests, SDK downloads, onboarding workflows, usage dashboards, or several content roles.

Documentation access and API authorization are separate systems. Giving someone the reference does not grant permission to call the API.