OpenAPI 3.2 now fully supported

We released a partial OpenAPI 3.2 support in late 2025. That support is now complete: deploy your OpenAPI 3.2 documents as usual and get the best of its new capabilities.

Nested navigation #

OpenAPI 3.2 lets you give tags a kind and a parent. Tags with kind: nav (or without any kind) build the navigation of your documentation, and parent turns them into a hierarchy:

• a tag used as a parent becomes a section of the navigation, titled with its name,
• its child tags become the groups of operations listed in that section.

tags:
  - name: Journeys
    kind: nav
  - name: Stations
    kind: nav
    parent: Journeys
  - name: Trips
    kind: nav
    parent: Journeys

If you already use x-tagGroups, the result is the same: this is its native OpenAPI 3.2 equivalent. x-tagGroups are still the way to go for OpenAPI <= 3.1 and Async API documents.

Badges #

A tag declared with kind: badge can be used to add badges to your operations, webhooks and channels.

tags:
  - name: Release candidate
    kind: badge

paths:
  /trips/{tripId}/live:
    get:
      summary: Stream live trip updates
      tags: ["Trips", "Release candidate"]

Streaming responses #

Streaming APIs send a sequence of items instead of a single payload. itemSchema describes each item of the stream.

responses:
  "200":
    description: A stream of trip updates
    content:
      application/jsonl:
        itemSchema:
          type: object
          properties:
            trip_id:
              type: string
            ...

Any HTTP method #

You can now document operations using any HTTP method with additionalOperations:

paths:
  /cache/{key}:
    additionalOperations:
      PURGE:
        summary: Purge a cache entry

Also in OpenAPI 3.2 #

New in this release:

• Example dataValue: the example data before serialization, displayed in request and response examples.
• Example serializedValue: the example as sent over the wire, displayed in request and response examples without reformatting, and used in cURL samples for path and query parameters.
• Security requirement by URI: a security scheme referenced by its path instead of its name, displayed like other security requirements.
• OAuth 2 deviceAuthorization flow: the flow for devices without a browser, displayed with its Device Authorization URL.
• OAuth 2 oauth2MetadataUrl: the authorization server metadata URL, displayed on the Authentication section.

Already supported:

• QUERY method: a safe request carrying a body, displayed in the documentation and available in the API Explorer.
• Security scheme deprecated: a security method soon to be removed, displayed with a deprecation badge.
• Tag summary: a short display name, used instead of the tag name.
• Server name: a short server label, displayed in the server selector.
• Response summary: a short response description, displayed alongside the response.

You can deep dive into OpenAPI 3.2 with our OpenAPI guide, updated for this new release.

As always, don’t hesitate to reach out if you have any feedback!

MCP server logs

MCP servers now keep a persistent history of every tool call: which tool was invoked, when, from where, whether it succeeded, and how long it took. Where debug sessions only cover a short live window, logs stick around. Use them to see how a server is actually used, and to investigate an issue after it happened.

You can also surface custom execution data by defining custom analytics in your workflow definition document. Runtime expressions let you pick the inputs, outputs or configuration values, and inspect them without opening a debug session. Authentication data is always excluded. Logs are stored anonymously, with nothing tying them back to personal data.

Find it in your MCP server settings, and learn more in the help center.

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

API changelog now accessible from your docs MCP servers

AI tools connected to your doc MCP server can now answer questions like “What changed recently on this API?”, straight from your documentation changelog. Two new tools are available:

• list_changes: browse the changelog of a documentation.
• get_change: retrieve the full content of a specific change.

The doc MCP server runs on top of the Portal API, meaning these two tools are also exposed as endpoints, if you need to access the changelog programmatically.

As always, don’t hesitate to reach out if you have any feedback.

Custom OAuth server and custom domain for your MCP servers

Our last release add two new ways to make your MCP server integrate more deeply into your ecosystem.

Bring your own OAuth server #

Private MCP servers no longer require a Bump.sh account for your users. If you already run your own identity provider (Okta, Auth0, Keycloak, etc.), you can delegate authentication to it instead: your users sign in the way they already do, and get access to your MCP server without ever touching Bump.sh.

Just provide your OAuth authorization server URL in your MCP server settings, we’ll handle the redirect. Learn more in the help center.

Custom domain #

Your MCP server URL can now live under your own domain, as you do for your API docs. Simply set up a CNAME record and add the custom domain in your MCP server settings. More about it in the help center.

The MCP Platform is now out of beta and available on all plans. Go to your dashboard to give it a try! Any questions or feedback? Reach out at hello@bump.sh.

API docs up to 5 times faster

Performance is an ongoing effort at Bump.sh. Our goal has always been to make your API users find what they’re looking for as quickly as possible, and performance is part of that goal. Following recent updates, we’ve seen performance gains of up to 500%, especially on large documentation.

To get there, we made multiple improvements:

• API definition files are now prepared and stored more efficiently, reducing processing time,
• Database queries have been optimized to serve your documentation faster, even under heavy load,
• Our caching strategy has been deepened to ensure that, most of the time, API users hit pre-generated content instead of waiting on cold requests.

These gains are most noticeable on large hubs and API documentation with deep request/response bodies.

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

Introducing Bump.sh Portal API and MCP server

API documentation is becoming headless. It’s no longer just humans browsing docs in a browser: LLMs and agents need to search and access them programmatically too. To support this shift, we’re launching two things at once: the Portal API, and an MCP server built on top of it.

Portal API #

The Portal API exposes the same three core capabilities as the portal UI: search, browse, and read. It gives programmatic access to a documentation.

Three endpoints are available:

• List: to explore a documentation structure and have a high-level understanding of the API capabilities.
• Search: to find relevant pages by keyword or natural language query, with optional filtering by type (operation, schema, topic, etc.).
• Fetch: to retrieve the full content of any page in a clean, token-friendly format.

The Portal API currently works for public docs. No authentication required. Check out the API documentation on Bump.sh.

MCP server #

The MCP server uses the Portal API (and Bump.sh MCP platform) under the hood. It lets any LLM or agent search and read docs in a token-efficient way.

The MCP server URL follows a simple pattern: any hub or API MCP server can be accessed by adding /mcp at the end of its URL. Each MCP server is scoped: a hub MCP server gives access to that hub’s docs only, and an API doc MCP server gives access to that specific API’s docs only.

The feature is active by default and can be disabled in the Ask AI section of your hub or API settings.

It is made available to your end users via the Ask AI dropdown, which provides links and clear instructions for installing the MCP server.

Docs MCP servers are currently available for public hubs and docs.

Learn more in the help center.

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

Run Arazzo workflows on your MCP servers

You can now use your Arazzo documents to run workflows on Bump.sh MCP servers. Arazzo is a workflow specification from the OpenAPI Initiative that extends your existing OpenAPI documents by describing how to sequence operations to accomplish real tasks.

You can deploy Arazzo documents using the CLI or the GitHub Action. Web upload using the dashboard isn’t supported yet.

Wanna learn more about Arazzo? Head over to our Arazzo guide for a full walkthrough of the specification.

Choosing between Arazzo and Flower #

You can now describe your workflows using one of these two specifications:

• Flower, our own lightweight specification.
• Arazzo, the specification supported by the OpenAPI Initiative.

We initially built Flower to describe simple workflows without having to add references to OpenAPI files: the specification felt overkill during our MCP platform building phase. As we started writing more complex workflows, we deepened Flower capabilities. It now supports data transformation between steps that Arazzo doesn’t support.

You can use Arazzo when you have OpenAPI definitions and want the portability of an OAI standard, and use Flower when you need something lighter or deeper data manipulation at the step level.

Any questions or feedback? Reach out to us anytime.

Roles requirements

Your users need to know what authentication methods are required, but they also have to know what access level or roles are needed to start sending requests to specific endpoints. There’s currently no way to describe it in OpenAPI: that’s why we are introducing x-rolesRequirements. Combined with security schemes, it gives your users a complete picture.

The x-rolesRequirements property can be added to any OpenAPI/AsyncAPI operation. It can either be an array of strings or a string:

paths:
  /clusters:
    post:
      summary: Create a new cluster
      x-rolesRequirements:
        - Organization owner
        - Product owner
      # ... rest of operation
  /clusters/{id}:
    get: 
      summary: Get cluster details
      x-rolesRequirements: "Cluster privileges: read"
      # ... rest of operation

Changes to role requirements don’t create changelog entries: you can update them without affecting version history.

Learn more about it in our help center

As always, don’t hesitate to reach out if you have any feedback.

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.