Octri
API StudioAPI documentation

Docs that update themselves when your API does

Reference pages, a live console, search and an agent-readable index, written from your spec and rebuilt whenever it changes.

Start for freeSee it live

A site for your readers

The site they land on

Reference pages, guides, search, and a console they can send a real request from.

What they see

A studio for you

Every word is yours

Every endpoint arrives written. Change any word of it, publish when you are ready.

What you do

An interface for agents

Docs a model can read

The same docs as plain markdown, an index at llms.txt, and your endpoints as callable tools.

What models get
GenerateOpenAPI docs generator

One click writes the docs for every endpoint in your spec

Point Octri at your spec and press generate. Every path and method in it gets a written reference page, automatically, on a site that is hosted, searchable and live on your own domain. Where your spec documents an endpoint properly, that endpoint ships in your own words with no model involved, and a rewrite only happens if you ask for one.

What goes in

  • OpenAPI 3.0 and 3.1, Swagger 2.0, Postman and AsyncAPI, in JSON or YAML
  • Your base URL and auth scheme, detected from the spec and filled in for you

What one run covers

  • The whole API, whether the spec holds 12 endpoints or 400
  • Or only the gaps, so the endpoints you added this morning catch up with the ones you documented last year
  • Any single page on its own, with the rest of the site left alone

What stays yours

  • You see what a run will touch before it starts, down to how many endpoints have nothing written and how many carry edits of your own
  • Your edits outrank the generator. A second run leaves them where they are, and dropping them is something you have to ask for
The published siteHosted documentation site

A spec lists your endpoints. The page explains them

The reference your readers land on carries more than the spec put into it. An explanation per endpoint, a description per field, and an answer for every error it can return.

  • Every endpoint explained, what it is for and when to reach for it
  • Every field described, including the nested ones nobody gets to
  • Errors answered status by status, what caused it and what to do next
  • Runnable examples on every endpoint, in cURL, JavaScript and Python
  • Deprecations flagged on the page, so nobody builds against what you are removing
Try itAPI playground

A console that actually calls your API

  • A form built from your schema
  • Snippets generated from what the reader just typed
  • Works with your auth, pointed at your real API
Find itDocs search and AI chat

Search it, or just ask it

  • Full search in a modal, autocomplete in the sidebar
  • Chat answering from your docs, on every page
  • Yours to switch off, and then no reader can reach it
See a live example
The studioDocumentation editor

The page you edit is the page they get

A generated page you cannot fix is worse than no page. The draft opens as the finished endpoint page, and you change it there, including the parts that came out of your spec.

  • Edit in place on the real page, so what you are looking at is what ships
  • Fix the spec from inside the docs: add a parameter, describe a field, document the response nobody did
  • Prose by default, MDX when you want the control
  • The docs and the SDKs come off the same spec, so one merged PR rebuilds the pages, the clients and the changelog together, in under 90 seconds
The API Studio in front of the site it publishes, both showing the same endpoint page. A sentence of the description is rewritten and a parameter that had none is given one, both on the page itself; pressing Publish brings the reader's site forward carrying those changes, with the page unmoved between the two.
The guidesGuides and tutorials

A reference is for looking things up. A guide is for getting started at all

There is always writing the spec has no room for. Quickstarts, auth walkthroughs, and the note explaining why v2 broke.

  • You arrange the navigation, guides and reference in one tree
  • Eighteen components built in: accordions, callouts, cards, code groups, field lists, media, steps, tabs and more
  • Nothing here is generated, a guide is yours from the first keystroke
  • Accordion
  • Callout
  • Card
  • Code group
  • Fields
  • Media
  • Steps
  • + much more

Your own components

The built-ins are a starting set. Add your own to it.

They stay where they are. Yours are added beside them, and what you build is a component like the ones that shipped with the product.

  • Built visually or written in MDX, whichever the component deserves
  • Props with defaults, so one component covers a family of cases
  • Styling that stays inside it, scoped so it cannot reach the rest of the page
  • Composable: a component you build can use the ones you built before it
Agentsllms.txt and MCP

People read the page. Models read the markdown behind it

The machine-readable half of your docs is built from the same content as the page, and it publishes when the page does. Nothing extra to generate, nothing to keep in step.

One endpoint of a published API reference in the three forms it ships in at once: the page a reader lands on, the same page as markdown for a model to read, and its row in the site's llms.txt index.

llms.txt

An index of every page and endpoint. It cannot go stale, because it is built the moment it is asked for.

Copy as markdown

The whole page in one click, headings, tables and code intact.

Your endpoints over MCP

An agent can call the endpoint it just read about, with nothing for you to host.

Indexing you control

None of it is compulsory. One switch takes the site out of the machine indexes, llms.txt included.

BrandingCustom domain and theming

The content is yours. So is everything around it

Your logo, typeface, colour and layout go in once. The whole published site takes them: reference pages, guides, search and the console.

  • Light and dark both designed, and the reader picks the one they want
  • Custom CSS when the settings run out
  • Your own domain on every tier, Free included. White-label from Business
One published API reference under three sets of appearance settings in turn: light and dark, three brand colours, sharp through fully rounded corners, three typefaces, three sidebar styles and widths, three code themes, and the contents rail switched off. The panel above the site shows the settings that produce each one.
MigrationMigrating your docs

Your migration is a file you already have

Whatever renders your reference today is reading an OpenAPI spec. Point Octri at the same one and you have a second site to hold against the one you are running.

  • Your URLs survive. Slugs are yours to set per page, so a path that exists today stays where it is
  • Guides come across as MDX and sit in the navigation beside the generated reference
  • Nothing switches until you move the domain. Your current docs stay up while you look at both

Read the comparisons before you move. On the blog →

The rest of itVersioning, SSO and GitHub sync

And the parts you only notice when they are missing

Publishing

  • Custom domainevery tier, including Free
  • Metadata done properly, so search engines find your API
  • Social cards you can preview first
  • You decide what gets indexed

Keeping it current

  • GitHub syncevery tier
  • A quality score on your spec, weak endpoints named
  • VersionsGrowth and above
  • A changelog with its own place in the sidebar

Who sees it

  • Private docs behind a password, or behind your SSO
  • Drafts stay inside your org until you publish
  • Nothing identifying a reader is recorded
  • Was this helpful, if you want to ask

Our documentation is built by the product it documents

It was generated from a spec and published on the same setup your own project would use, so what you find there is what your readers would find on your site the day you publish. The console runs live against our API, so you can watch the product work before you commit to it.

docs.octri.dev
  • Reference
  • Live console
  • Search
  • Ask the docs
  • Changelog
  • Agent index

Questions

Slugs are yours to set per page, so a path that exists today survives exactly where it is.

Your spec is already written

The docs are an afternoon behind it.

Start for free