# Octri > Octri turns one OpenAPI spec into hosted API documentation, idiomatic SDKs in ten languages, an MCP server and production monitoring, on a live URL that rebuilds when the spec changes. Octri is a hosted developer-experience platform for teams that own an OpenAPI spec. You connect a spec file, a spec URL or a GitHub repository. Octri writes reference documentation for every endpoint, generates client libraries, and keeps both current as the spec changes. The SDKs it generates report their own production errors. When a client throws inside a customer's application, the error reaches you tagged with the SDK version, the language and the method that failed, without your customer deploying anything. That is the capability that separates Octri from the other generators in this category. ## Products - [API Studio](https://octri.dev/api-studio): Documentation site generated from the spec, with a live request playground, full-text search, an ask-the-docs chat and an agent-readable index. Every page is editable and publishes to your own domain. - [SDK Studio](https://octri.dev/sdk-studio): Client libraries in TypeScript, Python, Go, Java, Kotlin, Ruby, PHP, Rust, Swift and Dart, shaped in a visual studio and published to their native registries including npm, PyPI, Maven Central, crates.io, RubyGems, Packagist and pub.dev. - [Monitoring](https://octri.dev/monitoring): Logs, issues, traces, performance, releases, uptime and alerts, covering both your API and the SDKs your users have installed. - [MCP Server](https://octri.dev/mcp): Seven documentation tools plus one executable tool per endpoint, generated from the same spec, for Claude, Cursor, VS Code and any other MCP client. ## From an OpenAPI spec - [Score an OpenAPI spec](https://octri.dev/openapi-audit): Free readiness audit: a spec scored out of 10 against the fourteen rules that decide whether a generated SDK is usable, with the whole rule catalogue published. No account, and the spec is not stored. - [Public OpenAPI spec scores](https://octri.dev/openapi-audit#public-scores): Index of well-known public OpenAPI documents scored for SDK generation, each with its own page at /openapi-audit/ giving the score, the fourteen rule results and sample finding locations. Derived facts only; the documents themselves are not stored or served. - [OpenAPI to TypeScript SDK](https://octri.dev/openapi-to-typescript-sdk): A typed TypeScript client from your OpenAPI spec, published to npm, with fetch or axios, auto-paging iterators and typed errors. Published to npm. - [OpenAPI to Python SDK](https://octri.dev/openapi-to-python-sdk): An async-first Python client from your OpenAPI spec, published to PyPI, with a choice of dataclass, pydantic or TypedDict models. Published to PyPI. - [OpenAPI to Go SDK](https://octri.dev/openapi-to-go-sdk): An idiomatic Go client from your OpenAPI spec, on the standard library, released by git tag so go get resolves it straight from your repository. Published to a git tag. - [OpenAPI to Java SDK](https://octri.dev/openapi-to-java-sdk): A Java client from your OpenAPI spec, published to Maven Central under a groupId you control, with typed models and typed errors. Published to Maven Central. - [OpenAPI to MCP server](https://octri.dev/openapi-to-mcp-server): How to turn a spec into an MCP server for Claude, Cursor and VS Code: the client config, the environment variables, and what an agent can read and call. ## Pricing - [Plans and limits](https://octri.dev/pricing): Free, then $49, $99 and $249 per month, plus a custom Enterprise tier. Annual billing takes 15% off the base price. SDK languages beyond the bundled count are $50 per language per month. ## Comparisons - [Compare Octri](https://octri.dev/compare): The whole field side by side, checked September 2026. - [Octri vs Speakeasy](https://octri.dev/compare/speakeasy): Generates client libraries. Octri adds the docs, the monitoring and a free tier. - [Octri vs Fern](https://octri.dev/compare/fern): Docs and SDKs, priced separately, with no monitoring. Octri adds the monitoring and one bill. - [Octri vs Mintlify](https://octri.dev/compare/mintlify): A documentation platform. Octri ships the SDKs and the monitoring as well. - [Octri vs Stainless](https://octri.dev/compare/stainless): Winding down. Octri is where its projects land, with monitoring it never had. ## Documentation - [Documentation](https://docs.octri.dev/documentation/guides/overview): Guides for the docs site: structure, editing, theming and publishing. - [SDK guides](https://docs.octri.dev/sdks/guides/overview): Generating, configuring and publishing client libraries. - [MCP guides](https://docs.octri.dev/mcp/guides/overview): Connecting an MCP client and choosing which endpoints it may reach. - [Monitoring guides](https://docs.octri.dev/monitoring/guides/overview): Wiring reporting, reading the workspace and setting alerts. - [CLI guides](https://docs.octri.dev/cli/guides/overview): Driving specs, builds and artifacts from the command line. - [API reference](https://docs.octri.dev): Octri's own API, documented in Octri. ## Writing - [Blog](https://octri.dev/blog): Product news and writing on API documentation, SDKs and developer experience. - [What counts as a breaking change when your SDK is generated](https://octri.dev/blog/breaking-changes-generated-sdks): A one-line spec edit can break every call site your users wrote. Here is the table of what is additive, what is breaking, and which ones your spec diff will not warn you about. - [Documenting webhooks in OpenAPI 3.1, and the half it cannot describe](https://octri.dev/blog/webhooks-in-openapi): 3.1 finally gave webhooks a home in the spec. It describes the payload, which is the easy part, and says nothing about delivery, which is where integrations break. - [API-first in practice: what changes when the spec is the source of truth](https://octri.dev/blog/api-first-in-practice): The phrase is used to mean four different things. Only one of them changes how your team works, and it is the one that makes the spec a build input rather than a report. - [Your operationIds are your public method names, and unique is not enough](https://octri.dev/blog/operationid-naming): An operationId is not documentation metadata. It is the name your users type. Here is why uniqueness does not save you, and what actually collides. - [Should you hand-write your SDKs or generate them?](https://octri.dev/blog/hand-write-or-generate-sdks): The honest answer depends on how many languages you ship and how often your API changes. For one language and a stable API, hand-writing wins. - [Getting your API docs cited when someone asks an AI about your product](https://octri.dev/blog/api-docs-cited-by-ai-search): People are asking assistants what your API does before they visit your site. What gets quoted back is decided by how your docs are structured, not by a file at your root. - [Publishing SDKs to npm, PyPI, Maven Central and the rest](https://octri.dev/blog/publishing-sdks-to-registries): Seven registries, seven sets of rules, and two languages that have no registry at all. The decisions you cannot take back are all made before the first release. - [41% of APIs drift within 30 days, and most of it is invisible](https://octri.dev/blog/api-schema-drift): Schema drift is not usually a breaking change. It is a field nobody told you about, found by a test that failed in CI two weeks later. - [Your MCP server needs documentation, and it is not your API docs](https://octri.dev/blog/documenting-your-mcp-server): There is no spec format for MCP servers yet, so what an integrator gets is a README and a config snippet. Here is what actually has to be in it. - [How many tools should an MCP server expose?](https://octri.dev/blog/how-many-mcp-tools): Exposing your whole API to an agent makes it worse, not more capable. Tool choice is a selection problem, and every extra option makes the selection harder. - [MCP vs OpenAPI: they answer different questions](https://octri.dev/blog/mcp-vs-openapi): The comparison is framed as a replacement and it is not one. One describes an API to people and compilers. The other hands a running agent a set of things it may do. - [Giving an agent write access to your API: what to exclude first](https://octri.dev/blog/agent-write-access-what-to-exclude): A tool call is a real request against a real API. Before you connect one, the question is not which endpoints to expose. It is which ones an agent must never reach. - [Modelling API errors in OpenAPI so your SDK can throw something useful](https://octri.dev/blog/modelling-api-errors-in-openapi): Most specs describe the happy path in detail and the failures not at all. That asymmetry lands on every consumer as one untyped catch block. - [The Octri CLI: Your Whole Project From a Terminal](https://octri.dev/blog/octri-cli): One binary pushes your spec, builds SDKs in ten languages, publishes docs, uploads source maps from CI, and reads back the production errors those SDKs report. It carries an MCP server, so an AI assistant can drive the same commands. - [llms.txt for API docs, and what AI crawlers actually read](https://octri.dev/blog/llms-txt-for-api-docs): A file at your docs root that tells a model what your product is and where to look. Cheap to publish, easy to get wrong, and not a substitute for the thing it points at. - [What your OpenAPI security scheme actually produces in an SDK](https://octri.dev/blog/openapi-security-schemes-to-sdk-auth): A security scheme is not documentation. It is the auth configuration your generated client ships with, and a spec that declares none produces a client with no way to authenticate. - [Retries, timeouts and idempotency: the parts of an SDK nobody hand-writes](https://octri.dev/blog/retries-timeouts-idempotency): Every client library needs them and almost no hand-written one has all three. The defaults matter more than the knobs, because most consumers never touch the knobs. - [Your changelog is part of your API](https://octri.dev/blog/api-changelog-is-part-of-your-api): Every integrator eventually asks the same question: did something change? If the answer lives in a release-notes page nobody subscribes to, they ask your support queue instead. - [The API docs your OpenAPI spec cannot generate](https://octri.dev/blog/what-openapi-cannot-generate): A generated reference answers what an endpoint accepts. It never answers which endpoint to call, in what order, or what to do when one fails. That part is yours. - [Why coding agents invent endpoints you never shipped](https://octri.dev/blog/agents-hallucinate-endpoints): An agent asked to integrate your API will recite one it saw in training or guess from the name. Both produce code that looks right and does not run. The fix is not a better prompt. - [Four ways APIs paginate, and what each one does to your SDK](https://octri.dev/blog/api-pagination-conventions): Cursor, offset, page number, next URL. Your choice decides whether your users write a loop or you write it for them, and whether the loop is even correct. - [Inside Octri API Studio: Docs You Edit Like an App, Not a Repo](https://octri.dev/blog/octri-api-studio): API Studio is a three-pane visual workspace for your docs. Edit an endpoint, watch the page render beside it, drag pages into groups, tune the playground and SEO, and publish a version. No markdown-in-a-repo ceremony. - [Inside Octri Monitoring: Observability for the SDKs You Ship](https://octri.dev/blog/octri-monitoring): The SDKs you hand to other developers are the least-observed code you ship. Octri Monitoring watches them: de-minified stack traces tagged to a release, grouped issues, traces, performance, alerts, and a live tail. Included on every plan. - [Inside Octri SDK Studio: Tune Every SDK, See the Code Change Live](https://octri.dev/blog/octri-sdk-studio): SDK Studio turns every knob on your generated SDKs in a real UI, per endpoint, with a live preview of the code as you change it. Package names, retries, pagination, streaming, deprecations, auth, custom transforms, and which endpoints ship. - [Why generated SDKs break silently, and how to make them observable](https://octri.dev/blog/sdk-monitoring): Generated SDKs go dark the moment they ship. Here's why they fail silently in production, and the three pieces you need to de-minify their stack traces and see the failures. ## Optional - [Changelog](https://docs.octri.dev/changelog): What shipped, by date. - [Support](https://octri.dev/support): How to get help and what each plan includes. - [Security](https://octri.dev/security): Data handling, encryption and disclosure policy. - [Fair use](https://octri.dev/fair-use): What the metered limits mean in practice. - [Subprocessors](https://octri.dev/subprocessors): Third parties that process customer data. - [Terms](https://octri.dev/terms): Terms of service. - [Privacy](https://octri.dev/privacy): Privacy policy.