bitbucket v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-bitbucket-api-token

Custody

customer_vault

Injection

header (Authorization)

An Atlassian account API token for Bitbucket Cloud, held in the client's own secret manager. The stored material must be the complete Authorization header value: the word Basic, one separating space, then the base64 encoding of <atlassian-account-email>:<api-token>. Bitbucket documents that API tokens authenticate with HTTP Basic per RFC 2617 using the account email address as the username and the token as the password, that an expiry date is required at token creation with a maximum lifetime of one year, and that a token cannot be viewed or adjusted after creation — rotation means creating a new token and updating the stored value, and deleting a token in the Atlassian account settings invalidates that issued token. App passwords are deprecated by the provider and must not be substituted. Request the least-privilege scopes: read:repository:bitbucket, read:pullrequest:bitbucket and read:pipeline:bitbucket cover the three read capabilities; pullrequest.approve additionally needs write:pullrequest:bitbucket and pipeline.trigger additionally needs write:pipeline:bitbucket — scopes do not imply one another, so grant the write scopes only where the R3 capabilities are enabled, and nothing broader. Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself, and it must never substitute a different credential without an approved pack change. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• bitbucket-workspace (api, internal): https://api.bitbucket.org/2.0/repositories/WORKSPACE
• bitbucket-repository (repo, internal): https://api.bitbucket.org/2.0/repositories/WORKSPACE/REPO_SLUG

The registered host is api.bitbucket.org (Bitbucket Cloud). Bitbucket Data Center is a different product with its own host and API surface: this pack does not cover it, and a Data Center deployment needs its own separately reviewed pack rather than a host substitution into this one. WORKSPACE, REPO_SLUG and PULL_REQUEST_ID in the endpoint paths are placeholders the deployment substitutes with concrete values at registration time, before enabling: the pack is installed with the concrete paths it will actually call, not rebound per request. This pack registers only endpoints the public Bitbucket Cloud REST API documentation describes: listing a workspace's repositories, listing a repository's pull requests, listing a repository's pipelines, approving a pull request, and triggering a pipeline. Documented exclusions: pull request create, update, merge, decline, request-changes and comments (a comment notifies watchers and is judged by its documented effect), pipeline stop, pipeline schedules, deployment endpoints, repository variables, runners, SSH keys, webhooks, branch restrictions, and every endpoint outside the registered list — a documented exclusion, not an approximated capability; each addition is a pack change and requires its own review. Tiering rationale: reads sit at the R0 floor. pipeline.trigger is registered as deploy at the R3 floor because Bitbucket documents that the request body carries the caller-chosen target (branch, tag, commit or pull request), selector and variables, and its Run-a-pipeline reference documents an on-demand pipeline form whose request body is a full caller-supplied YAML definition (sent as application/yaml, with the target metadata in query parameters) that overrides the repository's bitbucket-pipelines.yml for that run — so the caller chooses the commands that run, not merely which existing pipeline starts, and an installer's intention is not a restriction; deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). pullrequest.approve is registered as approve at the R3 floor because the approval is recorded under the caller's identity and typically counts toward merge checks, and approve is one of the IRREVERSIBLE ACTIONS. AAES has not been certified by Atlassian; reviewable default, not a vendor guarantee.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pullrequests/ (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/bitbucket/rest/api-group-repositories/ (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/ (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/bitbucket/rest/intro/#authentication (retrieved 2026-09-21)
• https://developer.atlassian.com/cloud/bitbucket/rest/intro/#filtering (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.