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

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.

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.

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.

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.

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.
© 2026 Octri, LLC. All rights reserved.
Made by devs who got tired of hand-writing SDKs.