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

Give an agent a real task, an isolated sandbox and a result you can verify. Check the records and code the agent produces.

Test SDK behavior against named runtimes and versions. Successful imports and familiar web APIs do not establish full runtime compatibility.

Design deterministic failure scenarios alongside happy paths. Give humans and agents a safe place to practice the behaviors production integrations need.

Follow onboarding from discovery to a verified result. Track completed steps and find where developers get stuck without collecting secrets or customer payloads.

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.

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.

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.

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.

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.

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.

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.

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