How Octri fits together
Everything in Octri starts from a spec and belongs to a project. This page explains those pieces and how they relate, so the rest of the documentation makes sense.
The pieces
| Term | What it is |
|---|---|
| Organization | Your team's account. It holds members, billing and projects |
| Project | One API. It has its own spec, docs site, SDKs, MCP server and monitoring |
| Spec | The OpenAPI file that describes your API. A project keeps every version you import |
| Endpoint | One operation in the spec. It becomes a docs page, an SDK method and an MCP tool |
| Page | Something you write by hand in MDX. Pages sit beside your endpoints in the docs |
One spec, four products
| Product | What it builds from the spec |
|---|---|
| API Studio | A reference page per endpoint, with schemas, code samples and a playground |
| SDK Studio | A client library per language, with typed models and one method per endpoint |
| MCP Studio | One tool per endpoint, plus tools that read your docs |
| Monitoring | Errors, traces and latency, matched back to your endpoints and releases |
When the spec changes, spec sync decides how that change moves through them.
An endpoint has one visibility across the products. Hide it in API Studio or exclude it in SDK Studio and it leaves the docs, the SDKs and the MCP tools alike.
Drafts and publishing
The studios work on drafts. What you change in API Studio or SDK Studio stays in your working copy until you press Publish, so nothing reaches a reader or a customer by accident.
Each studio publishes on its own. Publishing your docs does not release a new SDK, and releasing an SDK does not change your docs.
Project settings are the exception: they apply as soon as you save. Drafts and publishing lists which is which.
Three ways to work
Each of these changes the same data, so you can mix them.