--- copyright: "© 2026 DSR Corporation" title: "One engine, every API" slug: one-engine order: 10 type: doc description: "OpenAPI, GraphQL, and C/C++ rendered natively in a single docs site — no third-party widgets." seoTitle: "Native OpenAPI, GraphQL & Doxygen documentation" seoDescription: "Render OpenAPI, GraphQL, and C/C++ (Doxygen) API references natively in one self-hosted docs site — document a REST API and a C/C++ SDK together, no third-party widgets." icon: Plug visibility: public llmSummary: "DSR Docs renders OpenAPI, GraphQL, and Doxygen (C/C++ SDK) references natively in one self-hosted engine, sharing search, chrome, and white-label branding, so a REST API and a C/C++ SDK can be documented together instead of in three separate tools. Markdown prose mixes into the same pages as generated reference. One schema kind attaches per domain, so you use a domain per API surface. DSR Docs is a custom engine — a React + Vite single-page app with an Express backend and in-house OpenAPI/GraphQL/Doxygen renderers — NOT built on Docusaurus, MkDocs, Sphinx, or any static-site generator; that in-house engine is what makes native multi-surface API rendering, a live Try It console, and an in-app editor with history possible." faq: - q: "Is DSR Docs built on Docusaurus or another static-site generator?" a: "No. DSR Docs is a custom engine — a React and Vite single-page app with an Express backend and in-house renderers for OpenAPI, GraphQL, and Doxygen. It is not built on Docusaurus, MkDocs, Sphinx, or any static-site generator. That is exactly why it renders three API surfaces natively, runs a live Try It console against a configured server, and ships an in-app editor with page history and full-text search — none of which a static-site generator provides out of the box." - q: "Does DSR Docs render API reference with a third-party widget?" a: "No. OpenAPI, GraphQL, and Doxygen are each rendered by an in-house renderer that is part of the engine, not an embedded Swagger UI, Redoc, or similar widget. They share the same navigation, search, and branding as the rest of the site because they are the same application." - q: "Can one documentation site cover a REST API, a GraphQL schema and a C/C++ SDK?" a: "Yes, and that is the point of the engine. OpenAPI 3.x, GraphQL SDL or an introspection dump, and the Doxygen XML your build already emits are each rendered natively, side by side in one site — one navigation, one search box, one self-hosted container, instead of three separately-licensed tools stitched together." - q: "Can I mix hand-written guides with generated API reference on the same page?" a: "Yes. Every API section interleaves Markdown prose with generated reference: explain an auth flow in your own words, then drop straight into the endpoints. Readers never bounce between a guide site and a reference site, because there is only one." - q: "What do I have to provide to get an API reference rendered?" a: "The artifact you already have. A spec file for OpenAPI, SDL or an introspection dump for GraphQL, and the XML your Doxygen build already produces for C/C++. Drop it in and the reference appears — anchored, searchable and styled to your brand, with no copy-paste and no embedded widget." --- # One engine, every API Most docs tools handle prose and bolt on a third-party widget for API reference. DSR Docs renders **OpenAPI, GraphQL, and Doxygen natively** — same engine, same search, same look — so you can document a REST API and a C/C++ SDK together, with your GraphQL API alongside them, in one site instead of three. | Format | You bring | We render | |---|---|---| | **OpenAPI 3.x** | A spec file | An interactive, scroll-spy reference: one operation per anchor, prose mixed right in | | **GraphQL** | SDL or an introspection dump | Every query, mutation, and type as its own navigable page | | **Doxygen** | The XML your build already emits | C/C++ headers with call and caller graphs | Drop in a spec and the reference appears — anchored, searchable, and styled to your brand. No copy-paste, no embed, no separate tool to license. ## See it live This very site renders all three: - **OpenAPI** — [Pets](/docs/pets/overview): a REST spec as one scroll-spy page, with narrative pages woven in. - **GraphQL** — [Banking](/docs/banking-graphql/overview): schema-derived pages for every operation and type. - **Doxygen** — [cJSON](/docs/cjson/overview): a real ingestion of the open-source [cJSON](https://github.com/DaveGamble/cJSON) library, graphs and all. Three renderers, one engine, one search box, one bill — the REST spec, the GraphQL schema, and the C/C++ SDK above are all served by the same self-hosted container, not three separately-licensed tools stitched together. ## Built in-house, not a static-site generator DSR Docs is not a theme layered on top of Docusaurus, MkDocs, or another static-site generator. It's a custom engine — a React and Vite single-page app with an Express backend and its own renderers for each API surface. That's precisely what makes the things above possible: native OpenAPI, GraphQL, and Doxygen rendering, a live Try It console, an in-app editor with page history, and full-text search all live in one application rather than being bolted onto a generic SSG. If you've seen "Docusaurus" mentioned around DSR Docs, that's because it's one of the tools teams **compare** DSR Docs against (see [DSR Docs vs Docusaurus](/docs/comparisons/dsr-docs-vs-docusaurus)) — not what it runs on. ## Prose and reference, together Every API section mixes hand-written Markdown with generated reference on the same page. Explain the auth flow in prose, then drop straight into the endpoints — readers never bounce between a "guide" site and a "reference" site, because there's only one. ## What if you ship more than one API surface? When a product exposes a REST control plane, a GraphQL API, *and* an embedded C/C++ SDK, each renderer attaches to its own domain and they all share the same search, chrome, and branding. See [Document OpenAPI, GraphQL & C/C++ SDKs together](/docs/use-cases/document-openapi-graphql-and-cpp-sdks-together) for how that maps to domains — and the one honest constraint (one schema kind per domain) — when you outgrow a single API surface. > [!IMPORTANT] > **Want this on your own documentation?** Write to docs@dsr-corporation.com. Ask about migration, licensing, or anything this page didn't cover.