Help | Sign up

Bump.sh helps you build a branded single source of truth, cataloging all your APIs. We’ve created the reference point for teams consuming and building APIs, no matter which technology they rely on.

Bump.sh keeps your API docs always synchronized with your codebase. With this Github Action your API reference is automatically generated - with changelog and diff - on Bump.sh from any OpenAPI or AsyncAPI file.

You can also use this GitHub action to generate and manage MCP server, based on any Arazzo or Flower file.

• Usage
• Inputs
• Contributing
• License
• Code Of Conduct

Start with creating a documentation on Bump.sh.

Once you've got an API Documentation set up, go to Settings > CI Deployment, copy the access token, then add it to GitHub Settings > Secrets > Actions as a new environment variable called BUMP_TOKEN.

Then you can pick from one of the three following API workflow files.

• Recommended: Deploy documentation & diff on pull requests
• Deploy documentation only
• Diff on pull requests only

This GitHub action can be utilized to interact with the MCP server and workflow definition hosted on Bump.sh:

• Deploy workflow document for your MCP server

This is the most common worklow that we recommend using, which will create two steps in your automation flow: a validation & diff step on code reviews, followed by a deployment step on merged changes.

.github/workflows/bump.yml

Important: make sure you adapt the name of the branch your deployment will target, aka your destination branch if relevant (main in the example above), replace <BUMP_DOC_ID> with your Bump.sh documentation slug or id, and point file: to your local API definition file (doc/api-documentation.yml).

If you only need to deploy documentation changes on push then you can use this workflow instead:

.github/workflows/bump.yml

Important: make sure you adapt the name of the branch your deployment will target, aka your destination branch if relevant (main in the example above), replace <BUMP_DOC_ID> with your Bump.sh documentation slug or id, and point file: to your local API definition file (doc/api-documentation.yml).

If you only want to have API diff posted on pull requests use this workflow:

.github/workflows/bump.yml

Important: make sure you adapt the name of the branch your deployment will target, aka your destination branch if relevant (main in the example above), replace <BUMP_DOC_ID> with your Bump.sh documentation slug or id, and point file: to your local API definition file (doc/api-documentation.yml).

You can deploy a documentation inside a hub by adding a hub slug or id. Note that the documentation will be automatically created if it doesn't exist by using the slug you defined with the doc: input.

.github/workflows/bump.yml

Important: make sure you adapt the name of the branch your deployment will target, aka your destination branch if relevant (main in the example above), replace <BUMP_DOC_ID> with your Bump.sh documentation slug or id, <BUMP_HUB_ID> with your Bump.sh hub slug or id and point file: to your local API definition file (doc/api-documentation.yml).

You can deploy multiple documentation inside a hub from a source directory by adding a hub slug or id and specifying a directory name in the file: input. Note that documentation will be automatically created if they don't exist.

.github/workflows/bump.yml

Important: make sure you adapt the name of the branch your deployment will target, aka your destination branch if relevant (main in the example above), replace <BUMP_HUB_ID> with your Bump.sh hub slug or id and point file: to your local API definition file folder (docs/).

Please note, by default, only files named {slug}-api.[format] are deployed. Where {slug} is a name for your API and [format] is either yaml or json. Adjust to your file naming convention using the filename_pattern: input.

Note that it can include * wildcard special character, but must include the {slug} filter to extract your documentation’s slug from the filename. The pattern can also have any other optional fixed characters.

Here’s a practical example. Let's assume that you have the following files in your path/to/apis/ directory:

In order to deploy the 3 services API definition files from this folder (private-api-users-service.json, partner-api-payments-service.yml and public-api-contracts-service.yml), you can set call the action like this:

You'll need to get the slug (or id) of your MCP Server, accessible on bump.sh: https://bump.sh/{your-organization}/workflow/set/{mcp-server-id}/tokens

Copy the slug (we can call it BUMP_MCP_SERVER_ID_OR_SLUG) and use it with command deploy, with link to your flower or arazzo specification:

.github/workflows/bump.yml

Documents following either Arazzo or Flower specification are supported.

More details about the MCP server feature are available on this dedicated help section.

This feature is currently in closed beta. Request an early access at hello@bump.sh

• doc (required unless you deploy a directory on a hub): Documentation slug or id. Can be found in the documentation settings on https://bump.sh/dashboard

• token (required): Do not add your documentation token here, but create an encrypted secret that holds your documentation token.

  • Your Bump.sh token can be found in the documentation settings on your API dashboard. Copy it for later usage.
  • In your GitHub repository, go to your “Settings”, and then “Secrets”.
  • Click the button “New repository secret”, name the secret BUMP_TOKEN and paste your Bump.sh token in the value field.

• file: Relative path to the API definition file or the API definition file folder. Default: api-contract.yml

• hub (optional): Hub slug or id. Needed when deploying documentation in a Hub. Can be found in the hub settings on https://bump.sh/dashboard

• branch (optional): Branch name used during deploy or diff commands. This can be useful to maintain multiple API reference history and make it available in your API documentation.

• overlay (optional): Path or URL of overlay file(s) to apply before running the deploy command. Follows the OpenAPI Overlay specification, and accepts multiple overlays separated by comma.

• command: Bump.sh command to execute. Default: deploy

  • deploy: deploy a new version of the documentation (or MCP Server ✨)
  • diff: automatically comment your pull request with the API diff
  • dry-run: dry-run a deployment of the documentation file
  • preview: create a temporary preview

• expires (optional): Specify a longer expiration date for public diffs (defaults to 1 day). Use iso8601 format to provide a date, or you can use never to keep the result live indefinitely.

• fail_on_breaking (optional): Mark the action as failed when a breaking change is detected with the diff command. This is only valid with diff command.

• mcp_server (required to deploy a workflow document on an MCP server): use the server id or slug (can be found in MCP server settings: https://bump.sh/{your-organization}/workflow/set/{mcp-server-id}/tokens). This is only valid with the deploy command (default command).

Bug reports and pull requests are welcome on GitHub at https://github.com/bump-sh/github-action. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

The scripts and documentation in this project are released under the MIT License.

Everyone interacting in the Bump.sh github-action project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.