Tuum is a cloud-native, API-first core banking platform. Its developer documentation is how developers, analysts and product owners at their customers and partners integrate their applications with Tuum — and it has to keep pace with a product that releases every three weeks.

We spoke with Sven Meimer, Product Owner for Tuum’s customer-facing documentation and user interface, about how GitBook let the team retire its own developer portal and publish its API reference automatically with every release.

Sven wants the docs to clear as much of the integration path as possible on their own. Some use cases will always need Tuum’s implementation team, but the bar is set high:

“We aim to make it work so well that readers don’t need any help from our implementation team.”

The challenge: a portal that cost developer time

Tuum’s customer-facing documentation covers much more than an API reference: release notes, operational guides for the Tuum interface, and technical docs for developers are all included. Sven runs all of it with one dedicated technical writer, while product domain teams help validate and proofread.

Tuum originally built and ran its developer portal in-house, but platform upkeep was eating into the engineering team’s workflows.

“We soon found that maintaining it took too much developer time for our small team, so we started looking for alternatives.”

The team already used GitBook for its user interface guide, which made it the natural place to look. They moved the developer documentation over in stages, and migrating the API explorer was the final step.

An API reference that publishes itself

Tuum generates its OpenAPI specifications from the codebase. Each product team owns its part of the spec, including the descriptions for endpoints and parameters, and the technical writers set the guidelines for how those are written and ordered. Quality checks happen in the regular release process.

After each release, a scheduled pipeline collects every specification due for publishing and compares it with what’s already live in GitBook. It adds or removes specs through the GitBook API, then publishes the new version by merging the branch in GitLab.

“Our API docs now run on a fully automated process, without any human intervention.”

Leaving the portal to a specialist

For Sven, the move is a case for handing support services to a provider that specialises in them.

“Our engineers build core banking. Running a developer portal to GitBook's standard would take them away from this, so handing it to a specialist was an obvious call.”

With the portal off their plate, the team spends its time organising Tuum’s customer-facing knowledge base, and on making the most of what GitBook adds.

“These features are constantly evolving, so we don’t need to worry about lagging behind the competition. In fact, it’s the other way around: we need to keep up with new features to get the most out of them.”

His advice to another fintech documenting an API of this size is short:

“Automate API doc generation and use a publishing service from a specialized provider like GitBook.”

Consistent docs with a style guide

With two people covering all of Tuum’s customer-facing docs, the team has also started handing more of the checking to GitBook’s quality tools.

Tuum’s docs site contains two sections: Getting Started and an API Cookbook. Its style guide contains rules that apply both sections, alongside rules specific to each. 

“The style guide has significantly sped up our writing and review process. The agent handles the general structure and common expressions, so human writers and reviewers can focus on the topic's details and specifics.”

The team has also tuned how rules apply at different levels of the docs, so a new topic like payments can open with a fuller introduction while an endpoint page keeps it to a sentence or two. Sven sees it as work that keeps improving as they refine the rules.

Finding what readers still need with content gaps

Content gaps is the latest addition. Individual reader questions that cover the same topic would typically be scattered among everything else readers ask. Content gaps gathers them over time and turns them into recommended docs updates to avoid the same questions going unanswered in the future.

“The agent does the dirty work by collecting questions on the same topic over a longer period and creating a meaningful summary, which is a very good starting point for further agentic work.”

Shortly after Tuum switched it on, the number of discoveries they could act on grew overnight. Each gap's summary from GitBook Agent now becomes a Jira task and the starting point for an AI writing agent — with GitBook Agent reviewing the draft before it goes live.

“We only started using the content gaps feature last week, and it seems like a gold mine for us.”

Looking ahead

For Tuum, GitBook turned a developer portal the team had to maintain into one it simply publishes to, release after release.

For other teams, the lessons are simple. Generate your API reference from the code and automate publishing, so a release never waits on someone copying specs by hand. Don’t build a developer portal when a specialised provider already runs one. And let quality tools do the checking a small team can’t, from keeping new updates consistent to showing which questions the docs still leave unanswered.

Still maintaining a developer portal you built yourself? Get started for free or reach out to our team to publish your API reference with every release, the way Tuum does.

Related resources:

→ Generate API references from your OpenAPI spec

→ Find the questions your docs don’t answer yet with content gaps

→ See how GitBook handles API documentation