Sazabi and Bitbucket: search a workspace by token, ask from a pull request

Last verified on Nov 8, 2026.

Bitbucket teams usually want one narrow thing from an observability tool: let it read the code, nothing more. Sazabi is AI-native observability and security. Its Bitbucket integration is built around a single credential scoped to a single workspace, so the agent can trace an error to a file and line without being handed an engineer's login.

What the Sazabi agent can do with Bitbucket

Bitbucket is a forge integration with two methods that do not enable each other.

Core integration. You provide the workspace slug and a Bitbucket workspace access token. Sazabi validates the token against the Bitbucket API before it saves anything. After that the agent has read access to the workspace's repositories. Once those repositories are mapped to a project, it can search and read source files and cross-reference a stack trace with the code that produced it. Two further surfaces exist. You can mention @Sazabi in a pull request comment and it replies in that thread, and review of new pull requests with inline comments is a limited release with its own toggles. A personal Bitbucket connection under connected accounts lets the agent act as you, and Sazabi prefers it over the organization token when both exist.

Sandbox CLI. This installs nothing new for you to run. The Bitbucket CLI, bb, is already in the agent's sandbox, and connecting it supplies BITBUCKET_TOKEN (an API token or app password) and BITBUCKET_EMAIL. The agent can then manage repositories, pull requests and pipelines in your Bitbucket account. An optional BITBUCKET_WORKSPACE sets the default workspace.

Questions it answers

• Which file and line in this workspace threw the error in the trace?
• Which repository owns the function named in a log line?
• What risk does this pull request add, asked from the pull request comment itself?
• Which pipelines ran for a repository, through bb?
• Is the token still good, or does the connection need attention?

A worked example: connecting with a read-only workspace token

The Sazabi docs show the connection as a CLI command that reads the token from an environment variable. The workspace slug here is invented.

export BITBUCKET_WORKSPACE_TOKEN=...   # your Bitbucket workspace access token
sazabi integrations connect bitbucket \
  --credentials "{\"workspace\":\"acme-platform\",\"apiToken\":\"$BITBUCKET_WORKSPACE_TOKEN\"}"

The token choice is the interesting part, and Bitbucket's own documentation explains why a workspace token fits. A workspace access token is a per-workspace password for integrating tools. It is not tied to a user's account, it is limited to a single workspace and the projects and repositories under it, and it takes scopes you set at creation. Bitbucket says these tokens cannot be viewed or edited later, so you replace one instead of recovering it, and they can carry an expiry date. Workspace access tokens are also a Premium-plan feature on Bitbucket's side.

For Sazabi's code search, the Read repository permission is enough. In Bitbucket's terms it equals the repository API scope and covers viewing repositories, including source code, but not pull requests. Pull requests are a separate permission in Bitbucket, so a token scoped only for code search does not grant them.

If the token is rejected, the docs point at two things: the slug must match the token's workspace, and the token needs repository read scope. A later "needs attention" status usually means the token expired or was revoked in Bitbucket.

How it fits with other integrations

Bitbucket is the Atlassian-side forge, so it often sits beside Jira for tickets. Teams on the other major forge use GitHub, which has a different app-based install. Add Slack to see issues in a channel. Everything Sazabi connects to is on the integrations index, and pricing lists plans.