Expose API Docs to External Customers
Expose API docs to external customers
Public docs and private runbooks on one site
How do I pick a site-wide access mode?
Mark each page public or private
Build a gated partner developer portal
You control who sees what, because you host it
Crawler caveat
How it works in DSR Docs
Expose API docs to external customers Expose your API reference to customers and partners while internal runbooks stay private by serving both from one DSR Docs deployment, using a site-wide guest access mode (open, gated, or private) plus a per-page visibility flag. The same site holds internal runbooks, on-call notes, and half-finished specs that must never leak, so the problem is not "publish docs" — it's publishing some of them, to some people, without standing up a second portal or copy-pasting content between tools. DSR Docs handles this with a site-wide access mode plus a per-page visibility flag, all on infrastructure you run yourself. One deployment serves both the public developer portal and the private internal docs; the boundary is data, not two systems. Public docs and private runbooks on one site Public documentation is anything an anonymous visitor can read without signing in — your customer-facing API reference and its guides. Private documentation is everything gated behind a login — internal runbooks, on-call notes, and unfinished drafts. DSR Docs draws that line with two controls that stack a site-wide guest access mode and a per-page visibility flag, so one site carries both without a second portal. How do I pick a site-wide access mode? Guest access mode (Admin → Access → Guest access mode) decides what an anonymous visitor — a customer who hasn't signed in, or a crawler — is allowed to see Mode Anonymous visitor sees --- --- Open The full public documentation, no login. Good for a wide-open public API portal. Gated The Welcome landing plus only the pages you marked . Everything else demands sign-in. Private Login required everywhere; nothing is anonymous. For the "external customers, private runbooks" split, gated is usually the mode you want public by exception, private by default. Mark each page public or private In gated mode, a page is private unless you say otherwise. Set in a Markdown page's frontmatter to expose it API, GraphQL, and Doxygen reference pages have no Markdown body — set the same flag per page in the owning domain's under . So your customer-facing REST reference and its guides go ; your section and unfinished drafts simply stay at the default and never render for logged-out visitors. Build a gated partner developer portal Not every audience should be fully public. In gated mode, a partner who needs deeper access signs in and — depending on their role (viewer, editor, admin) — sees the gated content too. Sign-in is passwordless magic-link. After the first admin exists, every new account needs an invite, so you decide exactly who gets a login. Customers read the public pages with no account at all; named partners get an invite and see more. That gives you a partner developer portal and a public API reference from one deployment, not two. You control who sees what, because you host it DSR Docs runs as a single Docker container on your own infrastructure (air-gapped capable). The access boundary isn't enforced by someone else's SaaS tier — it's enforced on your box, and the internal runbooks you keep private never leave it. See Self-hosted alternative to GitBook & ReadMe for what running the whole platform yourself buys you, and Ship a white-label developer portal if the public portal needs to carry a customer's brand. [!NOTE] Access mode and per-page visibility apply to the whole deployment, not to individual requests at one URL. Branding is likewise per-deployment. If you need genuinely separate public and partner portals with different URLs and looks, run more than one deployment rather than expecting one site to shape-shift per visitor. Crawler caveat Public pages are only added to and once an absolute base URL is set in Admin → Site & SEO. In private mode, emits and the sitemap is skipped entirely. Set your production HTTPS origin before expecting search engines and LLM crawlers to find the portal. How it works in DSR Docs 1. Admin → Access → set guest mode to Gated . 2. Mark customer-facing pages (frontmatter for Markdown, for API/GraphQL/Doxygen). 3. Leave internal runbooks at the default — they stay private. 4. Invite partners who need gated access; customers browse the public pages with no login. 5. Set an base URL so the sitemap and publish your public catalog. See SEO & discoverability for how guest modes affect the public catalog. DSR Docs is a commercial license you run on your own infrastructure, and that license isn't priced per seat, per viewer, or per published site — so opening the portal to more partners doesn't multiply the bill. See Documentation without per-seat pricing. [!IMPORTANT] Sounds like your case? Write to docs@dsr-corporation.com. We'll show you the engine on documentation like yours, and say plainly what a move would involve.