How does the Bitbucket REST API work and what are common automation patterns for repository management?
Quick Answer
The Bitbucket REST API (v2.0 for Cloud, v1.0+ for Data Center) provides programmatic access to repositories, pull requests, pipelines, and settings using OAuth 2.0 or app passwords for authentication. Common automation patterns include bulk repository configuration, PR automation, pipeline triggering, and compliance auditing.
Detailed Answer
Think of the Bitbucket API as a universal remote control for your workspace. Instead of clicking through the Bitbucket UI to configure 200 repositories one at a time, you write a script that sends the same instruction to all 200 simultaneously. The remote (API) speaks a specific language (REST with JSON), and you need the right batteries (authentication tokens) to use it.
The Bitbucket Cloud REST API lives at api.bitbucket.org/2.0 and follows RESTful conventions. Resources are addressed by URL paths like /repositories/{workspace}/{repo_slug}/pullrequests. The API supports standard HTTP methods: GET to read, POST to create, PUT to update, and DELETE to remove. Responses use JSON format with pagination via a 'next' URL for large result sets. Authentication options include OAuth 2.0 (for apps), app passwords (for scripts), and repository access tokens (for CI/CD). Bitbucket Data Center uses a different API at /rest/api/1.0 with basic auth or personal access tokens, and the endpoint structure differs from Cloud.
The pagination system uses cursor-based navigation. Each response includes a 'values' array with the current page of results and a 'next' field with the URL for the next page. The default page size is 10 items, configurable up to 100 via the 'pagelen' query parameter. For listing all pull requests across hundreds of repositories, you must handle pagination to avoid missing results. Rate limiting applies at 1,000 requests per hour for authenticated requests, with headers (X-RateLimit-Remaining) indicating your remaining quota.
In production, teams use the API for several automation patterns. Bulk configuration scripts apply consistent branch permissions, merge checks, and pipeline settings across all repositories in a workspace. PR automation bots create pull requests for dependency updates, auto-assign reviewers based on CODEOWNERS-like rules, and post comments with test coverage reports. Pipeline triggers use the API to start custom pipelines from external systems like Jira or Slack bots. Compliance teams run periodic audits that scan all repositories for exposed secrets, missing branch protection, or disabled pipeline requirements.
A gotcha that trips up developers: the Bitbucket Cloud API and Data Center API are not compatible. A script written for Cloud will not work on Data Center without significant changes to URL paths, authentication, and response formats. If your organization runs both, you need separate API clients or an abstraction layer. Another trap is the rate limit: scripts that iterate over repositories making multiple API calls per repo can exhaust the hourly limit quickly. Implement exponential backoff and batch operations where possible.