Search in all APIs

Until now, running a search inside an API doc could only search the active doc. With search scopes, you can now search an entire hub without leaving the API doc. This one-click switch from a doc-only search to a global hub-search ensures your users no longer get stuck with an empty search results list and no follow-up actions.

You can change the default search scope (current API or global) in your hub settings. API users can individually activate/deactivate it in the API search modal.

Any requests or feedback? Reach out at hello@bump.sh!

Introducing Bump.sh MCP platform

APIs are no longer consumed only by humans. AI agents need to interact with them too, in a reliable and controlled way.

Most approaches today rely on naive OpenAPI-to-MCP transformations: individual endpoints exposed as tools, no orchestration, no security layer. The result is fragile, hard to maintain, and risky to run in production.

This is why we have built the Bump.sh MCP Platform: thanks to declarative workflows, you can now turn your APIs into deterministic, production-ready MCP servers. No guessing at runtime, no glue code, no credentials leaking to the LLM.

Not a simple OpenAPI-to-MCP conversion #

Bump.sh MCP servers expose ready-to-use workflows, not individual endpoints. You define the goals your API users can achieve (e.g. “book a train trip”), and the MCP server follows the workflow you defined, step by step.

This means you keep full control of the orchestration. AI tools consume fewer tokens, and the execution is predictable and repeatable.

Declarative by design #

Your MCP servers are based on workflow documents written in YAML. No hidden logic: everything is versionable, reviewable, and CI/CD-friendly. If you already use Bump.sh for API documentation, the experience is the same: update your definition, deploy from your CI, iterate with your team.

Two specifications are supported:

• Arazzo (the OpenAPI Initiative standard) if you already have OpenAPI definitions
• Flower, our lightweight specification for simple cases where no OpenAPI document is needed

Built-in security #

Credentials never go through the LLM. Store your API keys using Secrets: they stay server-side, only used to authenticate requests to your APIs.

MCP servers can be private, just like API docs. Manage who gets access directly in Bump.sh or using your own custom authentication server. Thanks to our integrated OAuth support, your users authenticate in one click, directly in their AI tools.

When an AI agent calls your MCP server, the data plane is the component that executes your workflows and forwards requests to your APIs. It runs on a server separated from Bump.sh’s main infrastructure, and no sensitive data is stored or logged. By default (on self-service plans), the data plane is hosted by Bump.sh. For custom plans, you can host it in your own infrastructure to get full control over your data.

Observability and debugging #

When things go wrong with API workflows, identifying the root cause can get tricky. Each MCP server comes with a built-in live debugger that lets you follow each step of a workflow execution in real time. Debug sessions are secured and fully historized: you know exactly who triggered a session and when, giving you a complete audit trail of your debugging activity.

Join the closed beta #

Bump.sh MCP Platform is currently in closed beta. Sign up here to get early access and help us shape the product.

If you have any questions or feedback, reach out to us anytime.

OpenAPI 3.2: partial support

The OpenAPI Initiative released a new version of their OpenAPI specification in September: OpenAPI 3.2.

If you didn’t hear about this new version, feel free to read our OpenAPI complete guide, updated for OpenAPI 3.2.

We started supporting some of the features brought by this new version:

• The QUERY method is now supported in both the documentation and the API Explorer.
• Servers can now have a name, which can be combined with the existing description field to provide users with a clear context about a server’s usage.
• Tags now offers a summary property. Behaving like our existing x-displayName vendor extension, it gives a way to display a group name in the documentation that is different from the tag name.
• summary can be added to responses when the level of detail doesn’t justify the use of the existing description field.
• Security schemes can now be deprecated.

OpenAPI 3.2 definition files can be deployed through your usual deployment process: using our Github Action, our CLI, our API (now in OpenAPI 3.2 ✨), or directly in your Bump.sh dashboard.

As always, you can reach out at hello@bump.sh for any questions/feedback.

Ask AI, Markdown rendering & llms.txt

Many API consumers now rely on AI tools to help them quickly discover API capabilities. Conversational tools such as ChatGPT or Claude can be fed with documentation intended for humans, but that extra “human context” gives them more noise, impacting the AI tools’ relevance and increasing token costs.

Our latest release provides these tools with the right context, empowering your API doc consumers through their favorite AI tools.

Ask AI #

Users can now easily ask questions about an API in their go-to conversational tools and get top-notch results. An “Ask AI” option has been added in documentation next to its introduction, x-topics, groups, and operations, offering access to ChatGPT and Claude with the right, narrowed-down context, alongside a one-click Markdown access.

Markdown rendering #

Bump.sh now offers an alternative context optimized for AI tools through Markdown rendering.

To access the Markdown version of a documentation, simply add .md at the end of the URL (or /source.md if you have a custom domain, when the URL is the root of your documentation).

On a documentation root (example truncated for visibility purposes).

# Bump.sh Api

## Description
This is version `1.0` of this API documentation. Last update on Nov 28, 2025.
This is the official Bump.sh API documentation. Obviously created with Bump.sh.

The Bump.sh API is a REST API. It enables you to [...]


## Servers
- Production: https://bump.sh/api/v1 ()


## Topics
- [Authentication](https://developers.bump.sh/authentication.md)


## Endpoints and operations

### [Branches](https://developers.bump.sh/group/endpoint-branches.md)
- [Promote branch as the default one](https://developers.bump.sh/operation/operation-patch-docs-parameter-branches-parameter-set_default.md)
- [Delete a branch](https://developers.bump.sh/operation/operation-delete-docs-parameter-branches-parameter.md)
- [List available branches](https://developers.bump.sh/operation/operation-get-docs-parameter-branches.md)
- [Create a new branch](https://developers.bump.sh/operation/operation-post-docs-parameter-branches.md)
### [Diffs](https://developers.bump.sh/group/endpoint-diffs.md)
- [...]


## Webhooks

### [Documentation change](https://developers.bump.sh/group/webhook-documentation-change.md)
- [Structure change](https://developers.bump.sh/operation/operation-webhookdocstructurechange.md)

For a specific operation (example truncated for visibility purposes).

# Create a new version

**POST /versions**

Deploy a new version for a given documentation, which will become the current version.


## Servers
- Production: https://bump.sh/api/v1 ()


## Authentication methods
- Authorization token
- Basic token (deprecated)


## Parameters

### Body: application/json (object)
The version creation request object
- **documentation** (string)
  UUID or slug of the documentation.
- [...]


## Responses
### 201
Documentation version successfully created

#### Body: application/json (object)
- **id** (string)
  Unique id of your version.
- [...]

llms.txt #

LLMs crawlers face similar challenges when crawling API docs: they don’t know what they’re looking for, and are flooded with an overabundance of information. llms.txt provides context, telling crawlers what information can be retrieved behind each page of a documentation.

llms.txt is available on both hubs and docs, by adding /llms.txt at the end of the URL.

On a documentation (example truncated for visibility purposes).

# Train Travel API

## Description
API for finding and booking train trips across Europe.

## Servers
- Production: https://api.example.com (Production)

## Topics
- [Getting started](https://bump.sh/bump-examples/doc/train-travel-api/topic/topic-getting-started.md)

## Endpoints and operations

### [Stations](https://bump.sh/bump-examples/doc/train-travel-api/group/endpoint-stations.md)
- [Get a list of train stations](https://bump.sh/bump-examples/doc/train-travel-api/operation/operation-get-stations.md)
- [...]

Don’t hesitate to reach out at hello@bump.sh if you have any questions/feedback.

New search experience

Search is at the core of our doc portal experience: your users need to easily find what they’re looking for, as it’s a key part of their API discovery.

Because we know how crucial it is, we recently completely rebuilt it to make it more relevant, faster, and more reliable.

Relevance #

Having quick results is useless if they aren’t relevant. We have redesigned our relevance rules from scratch to ensure that we provide your users with what they are really looking for:

• We now display a single list of results instead of several categories: users mostly look for operations, so displaying properties and other content “by default” didn’t always make sense.
• That global result list is ordered based on how closely the query matches a result item, and on its type. For example, for the same result weight, an operation will be favored over a property,
• The depth of a result is also taken into consideration to calculate its relevance, because we know that a first-level property is generally more important (and therefore searched) than a deep property,
• We removed the 5 results per type limit and now return all relevant results,
• Typos are also now better managed, ensuring relevant results even when the search query contains typos.

Performance #

Quickly finding the right information is one of the keys to a good API discovery, and search is part of it. Search speed has been increased by a factor of 10. This is particularly visible on larger hubs and complex documentation, reducing the time from almost a second to a few milliseconds, making the search experience instantaneous.

Usability #

All this work is under the hood, but we also made improvements to the search interface itself: the visual hierarchy of result items has been fully reworked to increase readability.

Any feedback? Reach out at hello@bump.sh!

Dark mode customization

Since we started providing dark mode, we applied filters to make your light mode color and logo blend in dark mode. The thing is, it isn’t always enough to ensure branding consistency. You can now define a custom logo and color dedicated to dark mode.

The option is available in your hub/documentation settings, under “Customize UI”.

It’s not mandatory: we’ll keep applying filters if you don’t want/need to customize it, but it gives you flexibility.

Any request or feedback? As usual, you can reach out at hello@bump.sh!

Documentation enhancements and fixes

While achieving milestones on larger projects, we’ve also made many quality-of-life enhancements and bug fixes. Here’s the changelog:

Enhancements:

• Custom meta tags can now be added to the head of your documentation,
• Dead anchors now redirect to their parent operation instead of the top of the documentation,
• In Embed mode, the search placeholders now specify their context (« Search API documentation » vs « Search hub »), so users can differentiate the global search from the documentaion portal search,
• A confirmation modal has been added to the API Explorer before sending destructive requests to avoid unwanted losses,
• The scrolling experience has been globally reworked to ensure its stability,
• Hub categories can now filter the documentation selector in the top navigation bar. This way, readers only see relevant docs from the same category, improving navigation for them and giving admins clearer control over doc organization,
• The browser window.title is now automatically updated when scrolling between operations to display the current navigation context,
• Highlights now work for subtitles inside x-topics, and global/operation descriptions,
• x-feedbackLink now works with Swagger 2.0 definition files,
• Groups in the navigation bar are now collapsible, to facilitate the navigation between groups containing many operations,
• The “add custom domain” module has been reworked to provide better explanations and error messages,
• Branches can now be sorted alphabetically in ascending and descending order,
• Skeletons for previews have been enhanced,
• x-state badges can now have custom colors,
• Accordions can now be added in Markdown using <details> and <summary> tags,
• A logo dedicated to dark mode can now be added to ensure brand consistency,
• The API Explorer beta is completed. 🎉 Thanks a lot to all of our testers. Your feedback has been invaluable and helped us build an even better feature for all.

Fixes:

• Fixed wrong breaking changes when the case of an HTTP header was modified but not its value,
• Fixed a trailing issue that caused the branch switch to return 404s in some contexts,
• Fixed multiple text alignments in documentation,
• Fixed an issue that prevented some descriptions from being displayed in the documentation when defined next to allOfs,
• Fixed an issue with alternatives preventing some generated examples from being displayed in some contexts,
• Fixed a bug with Mermaid rendering that prevented the use of ELK diagrams,
• Fixed an issue that displayed the “Show more” button in properties even when everything was already displayed in some contexts.

Feel free to reach out if you have any questions or features you think are missing from the product. Knock at hello@bump.sh.

Custom meta tags

Custom meta tags allow you to add your own meta tags to the head of your documentation, for example, to enhance your own global search experience with filtering through facets based on these meta tags.

The x-metaTags array is composed of objects made of two elements:

• name: the value that will be given to the name attribute,
• content: the value that will be given to the content attribute.

Adding the x-metaTags to the root of your definition:

x-metaTags:
  - name: First meta tag
    content: First tag content
  - name: Second meta tag
    content: Second meta tag content

Will apply the tags in the HTML of your documentation page:

<head>
  <meta name="First meta tag" content="First meta tag content" />
  <meta name="Second meta tag" content="Second meta tag content" />
</head>

You can apply it at different levels of your API definition: root, topic, operation, … See the full list in our help center

Any feedback or requests? Don’t hesitate to reach out at hello@bump.sh!

API Explorer - OAuth2 implicit flow support

Supporting the “implicit” OAuth2 security scheme allows for an automated login experience for your API consumers in the API Explorer. To activate it, a vendor extension called x-client-id can be added to the definition file. Its value should be the ID of a dedicated OAuth client application created on your Authorization server to identify your API consumers.

The x-client-id property is added to your OAuth2 implicit flow object:

components:
  securitySchemes:
    "OAuth2 implicit flow":
      type: oauth2
      flows:
        implicit:
          authorizationUrl: "https://auth.example.org/oauth"
          scopes: {}
          x-client-id: "123456abcdef"

Example of the OAuth2 implicit flow experience for an API consumer already logged into the API’s cloud platform.

Learn more about it in our help center

As always, don’t hesitate to reach out at hello@bump.sh if you have any feedback!

API Explorer - Server variables

Server variables enable API Explorer users to customize the request server with predefined enums or custom strings. It’s useful to specify a server region or a client specific instance, for example.

Variables are defined in a server object:

servers:
  - url: https://{region}.bump.sh/{docId}
    description: The production API server
    variables:
      docId:
        description: Can be found in your documentation settings.
      region:
        enum:
          - "east-eu"
          - "west-eu"
        default: "east-eu"

In this example, two variables were added:

• docId is a string, and a description has been defined to help the API user find its value,
• region is an enumerated list, with east-eu being the default value.

The API Explorer renders each variable accordingly.

Learn more about it in our help center

Any feedback on this feature? We’re happy to hear them! Say hi at hello@bump.sh.