The Octri Blog
Product updates and practical writing on API documentation, SDKs, and developer experience.
Showing articles tagged #openapi.

An HTTP success status starts a stream; it does not prove the operation finished. Design explicit completion, interruption and recovery semantics.

Describe dependencies, inputs and success conditions across API calls. Use Arazzo to make integration workflows explicit alongside OpenAPI.

Derive public, partner and internal API descriptions from one base contract. Use repeatable overlays and validate each audience's output.

Use schema-driven and stateful tests to explore API behavior. Preserve minimized failures and add business invariants the schema cannot express.
Ten practical questions for evaluating generated SDKs: spec support, code quality, auth, errors, publishing, monitoring, and exit cost.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Fern and Octri both turn one API definition into docs and SDKs. Octri adds production monitoring Fern has no answer for, more languages including Rust, a nicer docs editor, and a free tier.