On Monday, Steve talked about our new API reference docs feature — and how it’s built on a foundation that we call computed content. Today, I want to dive into how we built that foundation, where the idea for computed content came from, and what it enables today and in the future.

Hi 👋 I’m Greg, a Product Engineer here at GitBook. I’ve been working on computed content for the last few months, and excited to tell you more today.

What is computed content?

Computed content is documentation that is created automatically from existing data or knowledge — and that auto-updates when the source data changes.

For example, our first use-case is API reference documentation, created directly from an OpenAPI specification. GitBook takes all the information within the existing spec file — including descriptions, formatting, and endpoints — and uses it to create an API reference. GitBook creates multiple pages, adds all the endpoints, and other data as blocks on each page. The result is beautiful API reference docs in GitBook, that automatically update when the source API specification file is edited.

Computed content can use data directly from the source to create docs. But it can also integrate other tools into the workflow — including AI — to generate rich, accurate content in seconds.

We know that a lot of teams use generative AI in their docs workflow. And while it’s a useful tool, right now AI isn’t great at generating technical documentation without the wider context about the topic or product.

But computed content can feed the AI existing data or information — so it can get to work organizing, formatting, and creating great docs with all the context it needs.

Why computed content is a game-changer

The goal of computed content is to automate parts of your documentation workflow. And that doesn’t just cut maintenance costs — it also helps you keep your docs up to date and improves consistency.

We know that these are among the biggest challenges our users face when it comes to their documentation. But with computed content, automated workflows are much easier to create and manage — and the results are more predictable.

Whether it’s API references, changelogs, or translated pages, we believe much of this work can — and should — be automated.

Where it started

As with most GitBook features, it started with user pain-points. Some people told us they wanted a way to generate docs automatically from OpenAPI specifications. Others said they wanted a simple, accurate way to translate their docs pages using AI.

We soon realized these weren’t isolated requests — they were examples of the same pattern: taking structured inputs and turning them into useful documentation.

We didn’t want a one-off solution. GitBook is built around strong primitives like spaces and pages, and we needed a system that would integrate with that model. So we set out to design something flexible, generic, and deeply integrated into the rest of the GitBook experience.

Laying the foundation

At the core of computed content is a new type of page: the computed page. These pages are read-only and don’t store content directly. Instead, they define an input — like an OpenAPI file or a source language — and from that input, we generate a tree of pages and their content.

To keep things fast and scalable, the generation process is split into two steps:

One API generates the table of contents (the page tree). Another API generates the content for each page on demand.

This separation means that when you use computed content to create new pages, we can display the structure of those pages immediately. Meanwhile, we can defer the heavier content generation until it’s actually needed — which is especially useful for more intensive operations like AI translations.

We built this logic into GitBook’s core and made it fully generic: computed pages define an input, we cache the result, and we subscribe to the input. Then, when the input changes, the cache is invalidated and the content is re-generated.

The evolution of computed content

We started with a prototype focused on AI-powered translation. You could select a space in GitBook and a target language, and it would generate translated pages using AI. We made a quick UI to see how it would work in practice.

The prototype was promising, so we invested in building out the foundations properly.

When we decided to modernize our OpenAPI support soon afterwards, we used computed content as the foundation. It let us implement rich, maintainable API references with very little manual effort from users. We refined the UI, fixed bugs, tested it internally, and finally opened it up to everyone to try.

The present and future of computed content

Today, computed content powers our OpenAPI integration, letting you generate complete documentation from a spec file. And soon, we’ll be ready to make the auto-translation feature that started this journey publicly available. We’ll talk more about that on Friday.

Looking to the future, we’re exploring other inputs — like generating changelogs from GitHub releases or FAQs from support requests.

The potential of computed content is huge. Any structured data that reflects your product or service can theoretically be used to compute relevant, always-updated documentation. And that’s exactly the kind of future we want to build.

We’ll have more to share about computed content and other exciting features in the coming weeks. Stay tuned for more — and in the meantime please join our GitHub community. It’s a great way to speak directly with us, and the whole team sees your feedback and suggestions.

→ Read the documentation

→ Get started with GitBook for free

→ Automatically generate auto-updating API docs with computed content