# Bitbucket Data Center — an integration for Buff

> Questions and answers right in the pull requests of your Bitbucket Data Center or Server — where the review happens.

[Marketplace](https://buff.systems/en/marketplace) Bitbucket Data Center

# Bitbucket Data Center

Issue trackers · publisher buff · version 1.1.0

Questions and answers right in the pull requests of your Bitbucket Data Center or Server — where the review happens.

[Download the connector](https://buff.systems/en/downloads) [How to install](https://buff.systems/en/marketplace/bitbucket-dc#usage) 3 of 4 tools only read

- The answer arrives as a comment in the same pull request and is analysed against its branch.
- The setup form — each integration has its own fields: address, scope, bot name and credentials.
- The connection is live: its own set of tools and its own allowed address.
- The connection check does not just say “ok”: it reports the Bitbucket version, the account and the number of repositories.
- What the integration will get is written on its card in the connector’s catalogue.

Click a screenshot to open it in full. All screenshots are from a working installation.

## Overview

Bitbucket Data Center has no issue tracker of its own — teams keep their tasks elsewhere and keep their code in Bitbucket. So the integration lives where the work is: in the pull request. A developer writes to the bot in the discussion, and the answer arrives there, analysed against the code of THAT branch, not the main one.

## Use cases

The situations it is installed for.

- ### A question about the code right in the review A reviewer has opened someone else’s pull request and does not understand why a change was needed in three places at once. Asking the author means waiting until tomorrow; reading the whole branch alone takes half a day. Result. They write to the bot in the discussion. The answer arrives there and is analysed against the code of THIS branch: what changes, why the three places are linked and what it affects. The review continues in the same window.
- ### What really changes here An eight-hundred-line pull request, and a simple question: what changes in substance, and what is missing. Result. The bot reads the changes as a single diff and answers to the point — what changes, what is left unfinished, where the tests do not cover the new code path. The answer sits in the pull request itself, next to the changes.
- ### A development task from a review discussion The review revealed that the change needs follow-up work, and that has to be written down somewhere before it is forgotten. Result. Buff drafts a development task from the discussion and returns the link as a comment. The review does not turn into a thread about who will create the task.
- ### This happened before — find where exactly The change looks suspiciously like last year’s, but the only person who remembers it is on holiday. Result. The integration searches the selected repositories and brings back related pull requests — earlier attempts at the same subsystem, the changes the current one depends on.

## Examples

What to write and what comes back. How the bot is addressed is set in the connection settings — here it is “@buff”.

1. @buff list what this pull request changes and what it is missing a comment in a pull request tool: `get_pull_diff` It changes three places: CSV parsing (a BOM is added), the response header (charset=utf-8 appears) and the export test. What is missing: the export from the scheduler takes another path and no BOM is added there — the file from the nightly job will open just as badly.
2. /research where the delay in the report comes from a comment in a pull request — this is how deep research starts tool: `get_pull` The word after the mention picks the work: without it — a short answer, “research” — deep research with a document, “task” — a draft development task. A slash command works too.
3. @buff what has already been discussed in this review? a comment in a pull request with a long thread tool: `get_pull` A short summary of the discussion: what was asked to change, what the author replied, what was agreed and what remains unresolved. Useful when a review drags on for a week and has thirty comments.
4. @buff find pull requests about catalogue caching a comment in any pull request of a selected repository tool: `search_pulls` Found 3 attempts at caching: • ACME/api!218 “Reset the catalogue cache after a price change” — merged • ACME/api!341 “Cache warm-up after a deploy” — merged • ACME/api!402 “Duplicates in results after invalidation” — open, similar to the current one

## What it does

### Answers against the branch of the pull request it was asked in

A question asked in a pull request is a question about the code of THAT pull request. The integration passes the repository and the branch along with the mention, the platform pulls a fresh copy of the repository and analyses the question on its branch, not on the main one. Here it is not a nice detail but the whole point: there is no other place for a question in Bitbucket DC.

### Reads the whole pull request

get\_pull gives the model the intent of the change and the whole discussion, get\_pull\_diff the changes themselves as a single diff. Both tools only read.

### Searches the selected repositories

search\_pulls goes through the repositories you selected and finds related pull requests — earlier attempts at the same subsystem, the changes the current one depends on. Also read only.

### Answers in the same discussion

add\_comment writes the answer where the question was asked. It is the only tool of the integration that changes anything — and it is unavailable at the stages where the model only reads. The connector checks that on its side.

### Starts work only when addressed

Neither an approval, nor a status change, nor a new commit starts anything: work is started by a direct mention — a mention or a slash command in a comment. The list of selected repositories is the access control: inside them any member can call the bot, outside them nobody can, and the integration will not write there either.

## How to use it

Everything happens on the machine where the connector runs. At no step do you need to open access to your network from outside.

1. Step 1 ### Installation takes one click Open the “Marketplace” section on the connector’s local page. Before installing you can see what the integration will get: the addresses it will be able to reach, which credentials it will ask for, whether it will receive calls and how many tools the model will see. The connector downloads a signed bundle from our registry and checks the signature before writing anything to disk. **Connector** ← scroll the frame → The access limits are written on the catalogue card.
2. Step 2 ### Setup: an address, a token and a list of repositories You need the address of your Bitbucket, an HTTP access token of the bot’s account and the repositories in PROJECTKEY/repository form. The form is built from the schema the integration declares about itself. The token stays in the connector: the integration does not see it. **Connector** ← scroll the frame → Each integration has its own form fields.
3. Step 3 ### Create a separate account for the bot Give it access only to the repositories where the bot should answer: the account’s permissions are the outer boundary, and the list of selected repositories is the inner one. Permission to read and comment is enough; the bot should not be an administrator. The token is created under the bot itself — Bitbucket does not let an administrator issue a token on someone else’s behalf.
4. Step 4 ### The same from the command line Installing without a GUI is an equal option, not a fallback: \`connector install bitbucket-dc\`, then \`connector instance add bitbucket-dc --config base\_url=… --config repos=ACME/api\`.
5. Step 5 ### Events arrive on their own After setup there is nothing to start: the integration watches the selected repositories itself. If you want it faster, turn on event receiving in the connector and add a Bitbucket webhook for the “Pull request → comment added” event; the connector issues the link and the secret itself and checks Bitbucket’s signature (\`X-Hub-Signature\`). **Connector** ← scroll the frame → Each connection has its own set of tools and its own allowed address.

## Access limits

The connector shows the same on your machine before installation. The list comes from the signed catalogue, not written here by hand.

Goes out to

only the addresses from the fields `base_url`

Credentials

api — the values stay in the connector, the integration does not see them

Webhooks

deliver — you open the port, if you choose to

| Tool | What it does | Access |
| --- | --- | --- |
| search\_pulls | Find pull requests by text — when a number is mentioned or context from a review is needed | read only |
| get\_pull | Read a pull request with its discussion — when the intent of a change or the course of a review is needed | read only |
| get\_pull\_diff | Read a pull request’s changes as a single diff | read only |
| add\_comment | Write a comment in a pull request | writes |

The integration runs as a separate process under its own operating system user: it does not see the connector’s key, does not read the files of other connections and cannot reach the network past the connector. More in the [security section](https://buff.systems/en/security).

## Requirements

- Bitbucket Data Center or Server — the cloud bitbucket.org is a different integration with a different API.
- An HTTP access token of the bot’s account with permission to read and comment on the repositories needed.
- Network access from the connector’s machine to Bitbucket — nothing needs to be opened from your network to the outside.
- A connector run with the right to create a separate OS user for the integration (root or CAP\_SETUID).
- Bitbucket DC has no issue tracker of its own: the integration works in pull requests. If your tasks are in Jira or Redmine, install their integration alongside.

## Questions

- **What about tasks? We could not find a tracker.**: There is none: Bitbucket Data Center has no issue tracker of its own. This integration works in pull requests; for tasks, install the integration of the tracker where they live.
- **Does the Bitbucket token go to your cloud?**: No. It is stored on the connector’s machine and never leaves it. The integration does not see it either: the connector inserts the token into the outgoing request itself.
- **Can the integration reach anything other than our Bitbucket?**: No. It goes out only through the connector, only to the address derived from the setup field, and only to REST API paths. The connector rejects everything else.
- **Will the bot be able to write to repositories we did not select?**: No. The list of selected repositories limits both reading and writing: a mention from an unselected repository does not start work, and an attempt to answer there is rejected by the connector itself.
- **Is the question analysed against the pull request’s branch or the main one?**: Against the branch of that pull request. The mention brings the repository and the branch, the platform pulls a fresh copy of the repository and analyses the question on it. If the repository is not connected to Buff as a code source, the bot answers against the main branch and says so in the discussion itself.
- **Can the bot start work on its own, without being addressed?**: No. Neither an approval, nor a new commit, nor a status change counts as addressing the bot — work is started only by a mention or a command in a comment.
- **Can the model accidentally write to a review during analysis?**: No. At the reading stages only the tools marked as reading are available. add\_comment does not get there, and the connector checks that on its side.
- **Do I need to open a port for webhooks?**: Not necessarily. Polling always works and needs no ports; receiving calls is a speed-up for those who have somewhere to direct it. The port is opened by the connector, one for all connections.

At a glance

- **Version**: 1.1.0
- **Publisher**: buff
- **Updated**: 2026-10-05
- **Size**: 20 KB
- **Tools**: 4, 3 read only
- **Credentials**: api
- **Webhooks**: deliver
- **Platforms**: linux-x86\_64, linux-aarch64

[Connector documentation](https://buff.systems/en/docs/connector) [How it works from an information security standpoint](https://buff.systems/en/security) [Ask a question about the integration](https://buff.systems/en/contact)

On this page

- [Overview](https://buff.systems/en/marketplace/bitbucket-dc#overview)
- [Use cases](https://buff.systems/en/marketplace/bitbucket-dc#use-cases)
- [Examples](https://buff.systems/en/marketplace/bitbucket-dc#examples)
- [What it does](https://buff.systems/en/marketplace/bitbucket-dc#abilities)
- [How to use it](https://buff.systems/en/marketplace/bitbucket-dc#usage)
- [Access limits](https://buff.systems/en/marketplace/bitbucket-dc#access)
- [Requirements](https://buff.systems/en/marketplace/bitbucket-dc#requirements)
- [Questions](https://buff.systems/en/marketplace/bitbucket-dc#faq)

Next

## Connect Bitbucket Data Center

Install the connector in your network, open its local page and install the integration from the catalogue. Nothing needs to be rebuilt.

[Download the connector](https://buff.systems/app) [Write to us](mailto:info@buff.systems)

Companies and sole traders can pay by bank transfer and receive closing documents