The Octri Blog
Product updates and practical writing on API documentation, SDKs, and developer experience.
Ten practical questions for evaluating generated SDKs: spec support, code quality, auth, errors, publishing, monitoring, and exit cost.

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.

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.

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.

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.

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.

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.

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.

How to generate API documentation from an OpenAPI specification, and how to keep it in sync so it stops drifting from your code.

A look at how incremental static regeneration and on-demand revalidation give you static-fast pages that update the moment your content changes.