We’re making big improvements to our OpenAPI support and API documentation rendering — so we’re replacing the editable API method block with a standard text alternative.
Last updated
Was this helpful?
Was this helpful?
Generating API documentation using an OpenAPI definition
This is by far the most advanced and flexible method. Teams can rely on their API definition and easily maintain up-to-date API documentation. We support the OpenAPI 3.0 standard to date. Here are a couple of examples:
Craft API documentation using traditional blocks This method gives you full freedom over what to display, and how. While this offers flexibility, you also have to update your documentation manually every time the API changes. Still, some people love documenting their APIs this way!
Manually inserting API method blocks This method gave people control over what they displayed in their docs, but came with some drawbacks:
When the source API changed, someone had to update the block manually
The way the API method block rendered was inflexible, which didn’t meet our users’ needs
The block simply didn’t offer as much information and space as an OpenAPI block
From our perspective, the API method block was very restrictive in what it could support. It also technically limited our ability to improve the OpenAPI documentation experience to the quality we know you expect from GitBook.
Monday 12 February 2024: You’ll no longer be able to insert API method blocks in the GitBook editor.
Monday 4 March 2024: We’ll automatically transition all pre-existing API method blocks to regular text blocks — read on for more details.
On Monday 4 March 2024, we’ll automatically change your API method blocks into other, standard blocks. Here’s how an API block will look after the transformation:
We’re confident that the editing and reading experience of translated blocks is going to be improved as a result. That said, we think API documentation is even better using OpenAPI definitions instead of manually written text.
OpenAPI is a standard that helps gather a lot of information about an API and present readers with that information consistently — and automatically. If you use definitions like Swagger, you can easily update the definition file when you update your API, and those changes will instantly sync to your docs, too.
The OpenAPI block improvements that we’re working on right now will show information like sample code to use an endpoint and a detailed list of attributes — all based on your API definition, rather than manual input. It’ll also make it easier to navigate between response types and languages for sample calls and show all the important information at a glance.
We’re testing the updated Open API block in our own developer documentation right now, so head over there to get a sneak peek. We plan to release it on the same day as we depreciate API method blocks, but we’ll share news on that soon.
