Bitbucket package v1.0.0

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.

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; each addition is a pack change and requires its own review.

Approval classification: reads sit at the minimum R0 tier. pipeline.trigger is registered as deploy at the minimum R3 tier 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 intended limits need a separate enforceable control; deploy is one of the designated actions requiring human approval. pullrequest.approve is registered as approve at the minimum R3 tier because the approval is recorded under the caller's identity and typically counts toward merge checks, and approve is one of the designated actions requiring human approval.

AAES has not been certified by Atlassian; review and test this configuration; it is not a vendor guarantee.