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.

Every error your generated SDK reports crosses a line: out of your process, over the wire, into our disk. Here is what is inside it, the two scrubbers it passes on the way, where it sleeps, when it dies, and how you make us forget someone.

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.

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.

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.

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.

Exposing your whole API to an agent makes it worse, not more capable. Tool choice is a selection problem, and every extra option makes the selection harder.

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.

A tool call is a real request against a real API. Before you connect one, the question is not which endpoints to expose. It is which ones an agent must never reach.

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.

One binary pushes your spec, builds SDKs in ten languages, publishes docs, uploads source maps from CI, and reads back the production errors those SDKs report. It carries an MCP server, so an AI assistant can drive the same commands.

A file at your docs root that tells a model what your product is and where to look. Cheap to publish, easy to get wrong, and not a substitute for the thing it points at.

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.

Every client library needs them and almost no hand-written one has all three. The defaults matter more than the knobs, because most consumers never touch the knobs.

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.