Document REST, GraphQL & C/C++ SDKs Together
Document OpenAPI, GraphQL & C/C++ SDKs together
Can one docs tool handle OpenAPI, GraphQL, and Doxygen?
Why is Doxygen C/C++ SDK documentation the differentiator?
Shared chrome, so it reads as one product
The honest constraint: one schema kind per domain
How it works in DSR Docs
Document OpenAPI, GraphQL & C/C++ SDKs together Yes — DSR Docs renders REST, GraphQL, and C/C++ SDK references natively in one self-hosted engine, using three purpose-built renderers OpenAPI 3.x for REST, GraphQL SDL or introspection, and Doxygen for your C/C++ SDK. Instead of each API surface living in a different tool with a different look, search box, and login, all three sit under one site, one search, and one set of brand colors — running on a single engine, entirely on your own infrastructure. DSR Docs is a single API documentation tool that renders all three natively in one self-hosted engine, so REST, GraphQL, and your C/C++ SDK sit under one site, one search, and one set of brand colors — running on one engine, entirely on your own infrastructure. Can one docs tool handle OpenAPI, GraphQL, and Doxygen? Most documentation tools do one API kind well and bolt the rest on as raw file uploads or iframes, so covering multiple API specs means running two or three products in parallel. DSR Docs is one engine with a purpose-built renderer for each Surface Source you provide What it renders --- --- --- REST OpenAPI 3.x JSON Operations grouped by tag, parameters, request/response schemas, server + auth pickers, and copyable code samples GraphQL SDL or introspection JSON Queries, mutations, subscriptions, and every type — cross-linked, with signatures, args, and inline JSON examples C/C++ SDK Doxygen XML tarball Compounds, members, descriptions, cross-refs, and Graphviz call / caller / collaboration graphs Why is Doxygen C/C++ SDK documentation the differentiator? The Doxygen renderer is the one embedded teams rarely find elsewhere, and it is the reason a single engine can cover your reference stack. You run on your headers locally, tar the XML output, and upload it; the engine parses it into a navigable reference with the diagrams inline. It handles the shapes real SDKs have — IoT/Zigbee stacks, kernel modules, embedded libraries — including a split-by- option so a large SDK's independent surfaces each navigate on their own. Shared chrome, so it reads as one product All three sit inside the same shell one sidebar, one site-wide search, the same GitHub-style callouts, Mermaid diagrams, and Shiki-highlighted code, and the same white-label branding (name, logo, colors, fonts) that hot-applies from the admin panel with no rebuild or restart. Long-form Markdown pages — architecture overviews, migration guides, getting-started — mix in alongside the reference, so narrative and generated docs live together instead of in separate silos. The honest constraint one schema kind per domain A domain in DSR Docs accepts Markdown plus one attached schema — OpenAPI, GraphQL, or Doxygen. They are mutually exclusive within a single domain. To cover several surfaces you create several domains (each becomes its own tab in the top navigation) a REST domain, a GraphQL domain, and a Doxygen domain, all in one deployment, sharing the same search and branding. [!NOTE] DSR Docs documents and renders your APIs — it does not generate client SDKs. It does, however, have a built-in Try It console the OpenAPI reference fires live HTTP requests against a configured server, with auth and a full request editor, and shows the response status, body, and latency — alongside copyable code samples. How it works in DSR Docs 1. Create a domain per surface ( Edit → New domain ), pick section-scroll layout, and attach the matching schema upload your OpenAPI JSON, GraphQL SDL/introspection, or Doxygen . 2. Add Markdown pages for the connective tissue — overviews, auth, migration notes. 3. Set your brand in the admin panel; it applies live across every tab. 4. Point at your production origin so and emit for search and LLM crawlers. Everything runs in one Docker container on your own box, running entirely on your own infrastructure, under a license that isn't priced per seat, per viewer, or per published site, so cost is a license plus the infrastructure you already run — not a subscription that meters every seat, viewer, and published site. [!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.