Octri vs GitBook

Every endpoint gets a page with a description, every request and response field explained, and each error documented by status code with its cause and fix. Each page shows the call through your own SDK in every language you publish, with a playground beside it, and every spec change becomes a dated changelog entry with breaking changes flagged, without anyone writing it.

Guides are MDX in a visual editor on the published page, with Git sync, a custom domain, password protection, full-text search, an ask-the-docs chat, llms.txt and a markdown copy of every page for coding agents, docs analytics, PDF export and redirects for pages you retire, all on every plan, Free included.

Octri generates TypeScript, Python, Go, Java, Kotlin, Ruby, PHP, Rust, Swift and Dart. Every client comes with typed models and typed errors, auth from your security schemes, retries with backoff, pagination, idempotency, server-sent events, multipart uploads and webhook signature checks, and lands in its repository as a pull request on every merged spec change, ready to publish to its registry.

SDK Studio sets client shape, method names and file layout for the whole project, one language or a single endpoint, with the generated code redrawn beside each change. The Free plan includes one language, Starter 2, Growth 4 and Business all ten, and the docs show each endpoint’s call through them.

Octri’s MCP server has seven tools for reading your docs (search, one endpoint in full, the endpoint list, guides, the changelog, your SDKs and the call in your own SDK) and one callable tool per endpoint, which makes the real request. Endpoints you excluded from your SDK get no tool, so the SDK settings double as the agent’s permission list.

It runs locally over stdio with credentials kept on the developer’s machine, or as a shared SSE server for a team, and the tool list exports in MCP, OpenAI and Anthropic formats. Readers get an ask-the-docs chat on the site itself, from the Free plan up.

Every Octri SDK carries an error reporter. It ships switched off, and the developer who installs your SDK turns it on with one option. From then on a failure in their application reaches your project with the SDK version, the language, the method and the status, grouped into issues and tagged to the release that introduced it. Credentials and personal identifiers are redacted inside the SDK before anything is sent.

Uptime checks are generated from the endpoints in your spec, an incident publishes to a status page on your own domain and to a banner across your docs, and backend packages in ten languages add logs, traces and latency targets per route, on every plan.