Bump.sh Lets Teams Group API Docs by Business Use Case

Bump.sh now lets teams add their own section level to API documentation navigation with an x-tagGroups vendor extension, according to its Sept. 25 product update. Operations can be grouped around business use cases such as “journeys,” “bookings” and “account” instead of only by endpoint tag.

How x-tagGroups works

The extension “lets you add a level to your navigation by defining your own sections,” Bump.sh said. A team declares each section in the API description and lists the tags that belong under it. Operations whose tags aren’t assigned to any section stay in their default place in the navigation, so a team can group part of an API without reorganizing all of it.

Which specs it covers

Bump.sh said x-tagGroups works on OpenAPI and AsyncAPI documents regardless of version. OpenAPI 3.2 offers a native route through the parent property of tags, which Bump.sh named as an alternative. The extension gives teams on older OpenAPI versions the same nested navigation without upgrading their spec.

An earlier MCP change

Bump.sh added persistent logging for its MCP servers in its Sept. 11 product update. The logs record each tool call, when and from where it was made, whether it succeeded and how long it took. Bump.sh said authentication details are excluded and the logs are stored anonymously.

The take

We think use-case sections fix tag-based navigation, which mirrors how a backend team split the endpoints and not how a developer approaches the task. A reader who wants to book a trip shouldn’t need to know which service owns reservations. The grouping lives in the spec, so teams can try it with one edit. Our read is that the cost is portability: x-tagGroups is a vendor extension, and the OpenAPI 3.2 parent tag property is the standard route. We’d use the extension now and move to parent when a team adopts 3.2.