Octri.dev

Octri is a platform that takes a single OpenAPI specification and generates four connected products from it: a documentation site, client SDKs in ten programming languages, an MCP server for AI agents, and production monitoring. It is built for API teams and developers who want their API documentation, client libraries, and agent tooling to stay current without maintaining separate pipelines for each. The core promise is that one spec generates all four products and keeps them in sync, so there is never a second place to go and update when something changes. The problem Octri addresses is what happens after an SDK is published. As the site puts it, that is the moment code leaves your visibility: it runs on someone else's machine, fails on someone else's machine, and you hear about it in a support ticket three days later. Without monitoring of any kind, the typical timeline is three days with the integration still broken in production, no visibility into what went wrong, and angry support tickets stacking up. The stated alternative with Octri is a nine-minute window to a shipped fix with zero support tickets and nobody noticing. The broader context is that APIs are increasingly consumed not only by human developers reading docs but also by AI agents, which, without a structured source like MCP, integrate an API from memory and hallucinate its surface. API Studio generates documentation from the spec, with AI writing the first draft for every endpoint that you then edit like a document, so nobody has to open the YAML. It produces three-column endpoint pages with schema trees that open a level at a time, a live try-it playground on every endpoint, MDX guides alongside the generated reference, and support for your own domain on every tier including Free. Changes are stored per page, so a new spec revision only disturbs the endpoints that actually changed, and regeneration works around your edits. The generated docs also run an OpenAPI readiness audit, scoring a spec out of 10 against the same rules SDK Studio uses, surfacing missing schemas, undeclared path parameters and awkward method names before anyone generates a client. Fourteen rules are checked, covering things like successful responses declaring a schema, unique operationIds, path placeholders having parameters, a declared server URL, described authentication, shared models in components and referenced with $ref, and documented request bodies. SDK Studio generates idiomatic client libraries in ten languages: TypeScript, Python, Go, Java, Dart, Ruby, PHP, Rust, Swift, and Kotlin. Each language gets per-language config for namespaces, pagination, idempotency and code style, so you can rename methods, exclude endpoints, pick your HTTP engine and folder structure. You can write custom hooks compiled into the client, available as beforeRequest and afterRequest, and the generator handles included capabilities like pagination and streaming. SDKs auto-publish to the registries their users already install from: npm for TypeScript with type definitions generated from your spec and a choice of fetch or axios; PyPI for Python, async first with optional sync variants; git tag distribution for Go with standard library HTTP; Maven Central for Java, signed, under a groupId on a domain you own; pub.dev for Dart, for Dart and Flutter alike; RubyGems for Ruby with a class-style client; Packagist for PHP so Composer installs it; crates.io for Rust with doc comments becoming rustdoc; git tag and Swift Package Manager for Swift, with no registry account; and Maven Central for Kotlin with OkHttp or Ktor. Build history shows exactly what shipped and when. Monitoring has two ways in: flip it on and the telemetry compiles into your generated SDKs, or drop the standalone package straight into your backend. Either way there is no agent to deploy and nothing to instrument. Monitoring is off by default and switches on from the dashboard. It provides logs you can query directly by level, route, status code or release; issues grouped by fingerprint, each with the function and file that threw it; traces showing one request end to end across client, server, cache, database and queue, with the slow span called out; a service map of every service, the calls between them, and the error rate on each edge; N+1 query detection that finds the same query fired in a loop and counts it across traces; synthetic uptime probes on a schedule with run history behind every endpoint; and alerts that fire on burn rate and regressions so a single stray 500 never wakes anyone. Errors are traced to a commit. The site describes alert examples including a checkout 5xx spike with a threshold of 25 in 5 minutes, a new-issue alert on first sighting, a regression watch when a resolved issue starts erroring again, auth failures at 100 in 15 minutes, a latency guard at 50 in 10 minutes, a rate limit surge at 200 in 5 minutes, webhook delivery failures, and transcription timeouts. Security is handled by redacting credentials and identifiers on the client side before an event leaves your process, then again at ingest, covering tokens and direct identifiers such as email, phone and IP, with personal context waiting on your app's consent under a pre-signed GDPR Article 28 DPA. The MCP server turns your API into context and callable tools for Claude, Cursor and any MCP client. Seven documentation tools let the agent search, read and navigate your docs, and there is one callable tool per endpoint so the agent can hit your API for real. The server is curated by SDK Studio, so your exclusion list becomes the agent's permission list, and installation is one line: npx @octri/mcp, with nothing to host. The unique approach across all four products is that they share one source. Deprecate an endpoint in API Studio and the SDKs mark the method, the agent tools stop offering it, and monitoring shows you who still calls it. Add a language, cut a release, or push a new spec and the same thing happens. Nothing republishes behind your back: a spec change produces a draft and a diff of what moved, you approve it, and that is when new SDK versions reach the registries. The stated outcomes for users are visibility into integration failures before support tickets are filed, faster time from spec change to shipped fix, and consistency across docs, SDKs, agent tools and monitoring without manual synchronization. The site frames the shift as moving from three days of an unnoticed production failure to a fix shipped in nine minutes. For migrating teams, the importer reads an existing config file, bringing across navigation, custom pages, SDK settings, endpoint overrides, and theme and logotype, so you do not start from a blank project; a call with the team and onboarding help are both free of charge. Concrete use cases described in the content include integrating with an API through an agent: a user asks an AI assistant to integrate with Acme's Assistants API, the agent connects through the Octri MCP server with 15 tools over MCP and the npx @octri/mcp command, searches the docs, finds relevant pages, reads the POST /v1/assistants body schema, and wires it up with a TypeScript SDK package. A second scenario runs the same flow through a Python SDK, adding an assistant that answers billing questions, calling POST /v1/assistants and using the acme.assistants.create() method from a Python package. A third use case is writing a payment integration against a reference that shows GET /payments with limit, order, after and before query parameters, a paginated response with data, first_id, last_id and has_more, and a generated TypeScript SDK request example. Monitoring use cases include triaging grouped errors like a TypeError on GET /assistants/{assistant_id} with event and user counts and a last-seen time, tracking a regressed rate limit error, and routing alerts to Slack channels or ops webhooks. The spec audit is its own use case: pasting an OpenAPI URL and getting a score out of 10 with every missing schema and undeclared path parameter listed, optionally publishing the score at a public octri.dev address for public specs only, with the document not stored. The target audience spans indie developers shipping real APIs, growing teams shipping fast, and scaling products that need more, with the pricing tiers named Starter, Growth and Business respectively, plus Enterprise for unlimited scale with SLA guarantees. Plans are not per-product, so you can leave one of the four switched off and turn it on months later without redoing existing setup. The Free tier covers side projects and first APIs with one SDK language, 50 API endpoints, 100 one-time AI credits, 100 MB of monitoring ingress per month, AI-enhanced docs and chat, GitHub sync, custom domain and registry auto-publish. Growth at $99/mo adds four SDK languages, 300 endpoints, 2,500 AI credits, 5 GB ingress, versioning and custom code and components. Business at $249/mo adds all ten languages, 600 endpoints, 5,000 AI credits, 20 GB ingress, white-label and SDK CDN hosting. Enterprise adds SSO/SAML, unlimited scale and the ability to self-host the generator and docs renderer in your own infrastructure. Extra SDK languages are a flat $50/mo add-on, and annual billing saves 15%. Support ranges from Community on Free to Email, Priority and Dedicated on higher tiers. Everything Octri does starts from a specification you already have written. Whether you need readable docs, installable SDKs across ten ecosystems, agent-callable tools, or visibility into production failures, the same spec drives it all and keeps driving it as it changes, which is the value proposition the platform is built to reinforce.