Bitbucket

Our Bitbucket integration collects metadata about your organization’s activity across repositories, pull requests, and deployments. We never read, transmit, or store source code. Sensitive data, such as branch names and pull request titles, are always encrypted.

Antenna supports both Bitbucket Cloud (your repositories are hosted on bitbucket.org) and Bitbucket Data Center (your organization hosts and administers its own instance, previously sold as Bitbucket Server).

Permissions

We request only the necessary permissions to analyze Git metadata. Below is a description of the scopes requested when connecting to Bitbucket Cloud:

Account: Ability to see all the user’s account information
Project: Access to projects
Pull Request: Read access to pull requests and collaborate on them
Repository: Read access to all the repositories the authorizing user has access to
Access runners: Access to runners (Pipelines on your own infrastructure)
Team: Ability to find out what teams the current user is part of

You can learn more about scopes for Atlassian Connect apps in Atlassian’s documentation .

For Bitbucket Data Center, we authenticate with an HTTP access token instead of an app installation. The token needs Project read and Repository read permissions.

Connecting Bitbucket Data Center

How the connection works

Antenna is a cloud-hosted service. There is no agent, collector, or appliance to install inside your network. All data collection happens as outbound HTTPS requests from Antenna to your instance:


  Antenna (AWS, us-west-2)                     Your network
┌──────────────────────────┐                ┌────────────────────────────┐
│  Data importers          │  HTTPS :443    │  Public DNS record         │
│                          │ ─────────────▶ │  + ingress (load balancer, │
│  Fixed set of five       │  GET /rest/... │    reverse proxy, or WAF)  │
│  egress IP addresses     │ ◀───────────── │                            │
└──────────────────────────┘  JSON metadata └─────────────┬──────────────┘
                                                          │ internal routing
                                                          ▼
                                            ┌────────────────────────────┐
                                            │  Bitbucket Data Center     │
                                            └────────────────────────────┘

Antenna initiates every connection. Your instance never calls us, so you do not need webhooks, outbound firewall changes, or any inbound allowance on your side. Ingress to your Bitbucket instance is the only thing that has to change.
One protocol and one port: HTTPS over TCP 443. The instance URL you register must use https:// on the default port. URLs with a custom port (for example https://bitbucket.example.com:7990 or :8443) are rejected. If Bitbucket listens on another port internally, terminate 443 at your load balancer or reverse proxy and forward to it.
REST API only. We call read endpoints under /rest/api/latest/ for projects, repositories, pull requests, pull request activity, commits, and users. We never use the Git protocol: SSH (port 22 or 7999) and git clone are not part of the integration, and no source code is read, transmitted, or stored.
Token authentication. Requests carry an HTTP access token as a bearer token over TLS. The token is encrypted at rest.
Scheduled polling. We backfill history when you connect, then sync incrementally every two hours.

What to set up

Requirement	Details
Public DNS record	A hostname for the instance that resolves from the public internet, for example `bitbucket.example.com`. Internal-only names do not resolve from our cloud.
Inbound TCP 443	HTTPS ingress to the instance, reachable from outside your network. This is the only port we need.
Valid TLS certificate	A certificate from a publicly trusted CA that matches the public hostname. Self-signed certificates and private CAs fail the TLS handshake.
IP restriction (recommended)	Restrict that ingress to Antenna’s five IP addresses so the instance is not exposed more broadly. See IP Allowlisting below.
Unmodified API paths	The ingress must pass `/rest/api/` paths through to Bitbucket and preserve the `Authorization` header.
HTTP access token	Created in Bitbucket with Project read and Repository read.

You do not need to open SSH (port 22 or 7999), allow any outbound traffic to Antenna, configure webhooks, set up a VPN or private link, or grant database access.

A common setup is a reverse proxy or load balancer in your DMZ that terminates TLS on 443, allows only Antenna’s source IP addresses, and forwards to the internal Bitbucket instance. Antenna only needs the public hostname to behave like the instance for REST API requests.

Connecting in Antenna

Create an HTTP access token

We recommend a dedicated service account user with access to every project you want to analyze, and a token set to never expire. A personal access token or a project access token (limited to a single project) also works. Grant Project read and Repository read.

Add the integration

In Antenna, go to Settings, select the Connected Apps tab, choose Bitbucket, then select Data Center.

Enter your instance details

Provide the Instance Base URL (the public https:// URL, with no port or query string) and the HTTP Access Token. Antenna validates the token against your instance before saving, so a failure here usually means the hostname is unreachable, the certificate is not trusted, or the token lacks read access.

Verifying connectivity

From a machine outside your network, confirm that the instance answers an authenticated REST request:


curl -i -H "Authorization: Bearer <token>" \
  https://bitbucket.example.com/rest/api/latest/projects

A 200 response with JSON means Antenna can connect. A DNS failure, TLS error, or timeout points to the hostname, certificate, or firewall rules rather than the token.

IP Allowlisting

If your organization restricts access by IP address, you must allow traffic from Antenna before connecting your Git provider. All of our API requests come from a fixed set of load balancer IP addresses, so an active allowlist that does not include them will block both sign-in and data imports.

Add all five addresses below. In tools that require CIDR notation, append /32 to each address (for example, 100.21.131.68/32).

IP address	Direction
`100.21.131.68`	Inbound and outbound
`54.200.57.76`	Inbound and outbound
`52.37.32.106`	Inbound and outbound
`44.241.124.75`	Inbound and outbound
`54.69.112.12`	Egress (outbound requests from Antenna)

When an address is missing from your allowlist, the connection often looks successful while requests fail in the background with 403 errors and no data appears in your reports. If you are unsure whether an IP restriction is active, ask your provider administrator to confirm before connecting, or contact us at support@antenna.dev.