The info property of an OpenAPI document contains metadata that provides an overview of an API, but what does it represent exactly? How did it evolve across the OpenAPI Specification versions? And how to can it be used and misused? This is the second post in the OpenAPI Specification Reference series.

No OpenAPI document without the openapi property, but what does it represent? How did it evolve across the OpenAPI Specification versions? And how to take advantage of it? This is the first post in the OpenAPI Specification Reference series.

Are you struggling to design consistent APIs? On the verge of losing sanity while checking every single property of every schema is camelCased? Never remembering the parameters to use for pagination? Spectral is the tool you need: it will lint JSON Schema, AsyncAPI, and OpenAPI documents and do those checks for you.

The OpenAPI Specification can facilitate everyone’s life and participate in the creation of better APIs and a better API ecosystem. But it will work only if the members of the OpenAPI-based tools club follow the rules.

Supporting The OpenAPI Specification (fka. Swagger Specification) format when creating Web API tools is a must-have. Not for the sake of the format itself but rather because of the benefits you’ll get from it. But those benefits will come only if OpenAPI is used the right way.

OpenAPI, or the OpenAPI Specification, formerly known as the Swagger Specification, is a machine-readable and human-friendly API description format. That short description is correct but does not help to understand what it is OpenAPI: it’s the Rosetta Stone of the Web API world. Let’s see why.

Jumping into the API-first train, even only focusing on private/internal APIs, will have an impact on budgets. Organizations need to find ways to redistribute budgets in order to enable any team that needs to provide APIs to do it in the best possible conditions. Is monetizing private/internal API the solution? Would crowdfunding private make sense?

An often unintended consequence of an internal API-first strategy is having teams with not much IT jumping, willingly or not, in the API train. That inevitably will raise budget questions which answers will determine the success of the API-first strategy.

Let’s learn to use Twitter v2 API tweets lookup operations to render simple text tweets and their author just like Twitter does. We’ll learn a few things about API design and API documentation in general and Postman based API documentation in particular in the making. I hope this will give you some ideas for the design and documentation of your API.

An internal API-first strategy will inevitably raise budgets questions; you must be aware of that. One of them is who will pay for the brand new API platform and how? The success of an internal API-first strategy may depend on the billing model of the API platform.