Skip to content

Help center: add portal API/MCP changelog capabilities #473

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
grossyoan merged 1 commit into from
Jul 10, 2026
Merged

Help center: add portal API/MCP changelog capabilities #473

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 12 additions & 5 deletions src/_help/customization-options/headless-doc-portal-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,9 @@ title: Headless doc portal (API)
- TOC
{:toc}

The Portal API provides access to API documentation hosted on Bump.sh programmatically. The API returns structured content through a REST API call, with the same level of content as the visual API doc.
The Portal API provides access to API documentation hosted on Bump.sh programmatically. The API returns structured content through a REST API call, with the same level of content as the visual API doc.

[Check out the API documentation.](https://developers.bump.sh/doc/portal/)

> The Portal API currently works on public docs.
{: .info}
Expand All @@ -24,14 +26,19 @@ The Portal API is useful when you want to build your own integration on top of B

## Explore the documentation structure

You can use the [`GET /list`](https://https://developers.bump.sh/doc/portal/operation/operation-get-list) endpoint to list all child pages under a given URL in the portal hierarchy. It returns each page's URL, title, type, and a short description. It's useful as a starting point to understand what a portal contains before fetching specific pages.
You can use the [`GET /list`](https://developers.bump.sh/doc/portal/operation/operation-get-list) endpoint to list all child pages under a given URL in the portal hierarchy. It returns each page's URL, title, type, and a short description. It's useful as a starting point to understand what a portal contains before fetching specific pages.

## Search across documentation

You can use the [`GET /search`](https://https://developers.bump.sh/doc/portal/operation/operation-get-search) endpoint to search across all documentation pages in a portal by keyword. Results include URL, title, type, and a text excerpt for each page. You can optionally filter by page URL or by page type (`operation`, `model`, `guide`, etc.).
You can use the [`GET /search`](https://developers.bump.sh/doc/portal/operation/operation-get-search) endpoint to search across all documentation pages in a portal by keyword. Results include URL, title, type, and a text excerpt for each page. You can optionally filter by page URL or by page type (`operation`, `model`, `guide`, etc.).

## Retrieve page content

You can use the [`GET /fetch`](https://https://developers.bump.sh/doc/portal/operation/operation-get-fetch) endpoint to retrieve the full content of one or more pages by their URLs (up to 10 per request). Content is returned in Markdown format.
You can use the [`GET /fetch`](https://developers.bump.sh/doc/portal/operation/operation-get-fetch) endpoint to retrieve the full content of one or more pages by their URLs (up to 10 per request). Content is returned in Markdown format.

A common flow is to call `GET /search` first to identify relevant pages, then `GET /fetch` to read their full content.

## Retrieve the changelog

You can use the [`GET /changes/list`](https://developers.bump.sh/doc/portal/operation/operation-get-changes-list) endpoint to retrieve the changelog for a specific API or a hub, and then use the [`GET /changes/fetch`](https://developers.bump.sh/doc/portal/operation/operation-get-changes-fetch) endpoint to get the full content of a specific change.

@fbraure fbraure Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't talk about /changes/fetch here?

@grossyoan grossyoan Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do:

You can use the GET /changes/list endpoint to retrieve the changelog for a specific API or a hub, and then use the GET /changes/fetch endpoint to get the full content of a specific change.


A common flow is to call `GET /search` first to identify relevant pages, then `GET /fetch` to read their full content.
2 changes: 2 additions & 0 deletions src/_help/documentation-experience/ask-ai-capabilities.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,8 @@ The MCP server exposes three tools:
| **list_pages** | Lists all child pages under a given URL in the documentation hierarchy. Returns each page's URL, title, type, and description. Useful as a starting point to explore what documentation is available before fetching specific pages. |
| **search** | Searches across all documentation pages by keyword. Supports filtering by type (operation, schema, topic, authentication, webhook, etc.). Returns up to 20 matching results with their URL, title, type, and a text excerpt. |
| **get_pages** | Retrieves the full content of one or more pages by their URLs. Accepts up to 10 URLs per request. Use this when you already know which pages you need, for example from `search` or `list_pages` results. |
| **list_changes** | Lists all the changes of a documentation/hub. Returns each change's ID, URL, title, content, and creation date. |
| **get_change** | Retrieves the full content of a specific change. |

A typical request from an API user to the LLM, like "How do I do that using this API" will trigger the **search** tool to get the right API/operation, and then a **get_pages** to get the actual content.

Expand Down
Loading