Bitbucket integration

What it does

The Bitbucket integration wires a client's Bitbucket Cloud workspace into your workflows. Connect the workspace once and your triggers hear every push, pull request, commit comment and build status on the repositories you choose. Your actions work the other direction: opening, updating and merging pull requests, commenting on them, creating branches, setting build statuses, and reading repositories, commits, tags and workspace members.

Bitbucket's native issue tracker is not part of this. Atlassian removed it on 2026-08-20, so there is no issue automation to build here. Use Jira for that.

Connect a Bitbucket workspace

Bitbucket connects over OAuth 2.0. Your client authorizes TaskJuice on Bitbucket's own consent screen, through an OAuth consumer you create in your agency's Bitbucket workspace — so the screen your client sees carries your name, not TaskJuice's. Your client never types a credential into TaskJuice: you register the consumer's key and secret once, on Bitbucket's page under Apps, and the client only approves a consent screen.

1. Create an OAuth consumer in Bitbucket

   In Bitbucket, open your agency's workspace, then Settings, then OAuth consumers, then Add consumer. Give it a name your clients will recognize — it is what they see on the consent screen.

2. Set the callback URL

   TaskJuice shows the exact callback URL to paste on Apps → Bitbucket — copy it from there rather than typing it. It is your TaskJuice domain followed by /oauth/callback, and it differs if your account uses a custom domain, so a typed guess is the most common reason a first connection attempt comes back as a failure. Leave This is a private consumer unticked: it governs the client-credentials grant, which TaskJuice does not use.

3. Tick the permissions

   On the consumer's Permissions panel, grant the scopes in the table below and nothing beyond them — five of the six for most agencies, since account is only needed if a workflow lists workspace members (see the consequences under the table). Bitbucket presents permissions as grouped checkboxes rather than as scope names, and a group can grant more than one scope — so after saving, check the consumer's own summary of what it was granted against that table before you connect.

4. Register the consumer in TaskJuice

   Copy the consumer's Key and Secret. In TaskJuice, go to Apps, then Bitbucket, and save them as your own OAuth client. Tick exactly the same scopes there that you granted on the consumer — the two lists must match. Bitbucket is bring-your-own-client only: without this step, Connect returns an error.

5. Open the connection form

   You are done with the OAuth app. Scroll up to Accounts on the same Bitbucket page and click Connect account.

6. Enter the Bitbucket Workspace

   This is the client's workspace, not your agency's. The slug is the part after bitbucket.org/ in that workspace's URLs — for bitbucket.org/acme the slug is acme.

7. Connect and consent

   Click Connect Account. Bitbucket asks the client to authorize your consumer; approving it returns them to TaskJuice with the connection live. TaskJuice stores a two-hour access token and a refresh token, and rotates them for you.

8. Know where to revoke

   Deleting the connection in TaskJuice removes TaskJuice's copy of the token. It does not revoke the grant on your consumer. The client revokes that themselves in Bitbucket, under Personal settings, then App authorizations.

These are the twelve scopes TaskJuice uses:

Do not tick Repositories: Delete, Account: Write or Email, Issues, Wiki, Snippets or Runners. No TaskJuice action uses them, and TaskJuice cannot narrow a token Bitbucket issued more broadly than the scopes above.

Five consequences worth knowing before you tick them.

account is a scope many agencies can leave off. Only the workspace, user and permission reads need it — bitbucket/get-current-user, bitbucket/list-current-user-workspaces, bitbucket/get-current-user-workspace-permission, bitbucket/list-current-user-repository-permissions, bitbucket/list-workspace-members, bitbucket/get-workspace-member, bitbucket/list-workspace-permissions and bitbucket/list-workspace-repository-permissions — and TaskJuice only requires a scope that a published workflow actually asks for. If no workflow of yours reads members or permissions, leave Account unticked on the consumer and off the TaskJuice scope list. Read the reach note below before you decide to tick it.

Approving and commenting need only pullrequest, not pullrequest:write. Atlassian defines the read scope as giving "read access to pull requests and collaborate on them", and describes the write scope as what "adds the ability to create, merge, and decline pull requests" — commenting and approving are in neither of those three additions.

A webhook needs webhook plus the scope of every event it carries. The webhook scope alone only reads existing subscriptions; Atlassian's scopes reference states that creating a webhook for an event also requires that event's own scope. Atlassian has also said that receiving a delivery is gated the same way — an app without pullrequest never receives pullrequest:updated — though it published that in a change notice written for Connect apps, so treat the delivery half as the safe assumption rather than a documented guarantee for OAuth consumers. Either way it points the same direction, which is why every Bitbucket trigger asks for webhook and its event scope together.

Pipeline variables come back in plaintext unless they are marked secured. Bitbucket returns an unsecured variable's value on every read, and TaskJuice stores whatever a step returns in that run's data. A variable marked secured comes back with an empty value — Bitbucket's own words are that a secured value "will never be exposed in the logs or the REST API" — so mark anything sensitive secured at the Bitbucket end rather than relying on TaskJuice to hide it.

TaskJuice does not infer Bitbucket's implications, and you should not rely on them here. Bitbucket treats pullrequest:write as implying repository:write and pullrequest on the consumer, but the scope list you save in TaskJuice is checked for exact membership. A consumer with only Pull requests: Write ticked still needs all four of repository, repository:write, pullrequest and pullrequest:write listed on the TaskJuice side. Listing fewer blocks the publish with a named error; it does not silently narrow anything.

The right-hand column is what TaskJuice calls, not the limit of what each scope permits. repository gives read access to every repository the authorizing user can reach, including its source, and repository:write gives write access to the same set — Atlassian makes no distinction between public and private repositories. account is wider than its one row suggests: Atlassian defines it as the "[a]bility to see all the user's account information", which is the authorizing user's email addresses, full name, location, website, SSH keys and group memberships — read-only, but well beyond a member list. Grant them on an account you are willing to give that reach. And because Bitbucket fixes scopes on the consumer, ticking a broader box there hands TaskJuice a broader token than the scopes above: TaskJuice cannot narrow it, so tick exactly the boxes the scopes you actually need require, and nothing else.

Triggers

Pick a repository in the trigger's Repository field and publish. That is the whole setup — and for the four workspace events there is not even a field to pick.

TaskJuice registers the webhook in Bitbucket for you: it points the hook at an address only your workspace can receive on, subscribes it to the events your published workflows need, and sets a signing secret it generates and keeps. There is no webhook to create in Repository settings, no URL to copy, and no secret to invent. The trigger panel reports the setup state while it runs, and clears when Bitbucket confirms the hook.

Most Bitbucket triggers are per repository, and you pick that repository in the trigger's Repository field. Four of them — the workspace events below — are workspace-wide instead: they have no Repository field, and TaskJuice registers a single workspace-level webhook for them.

The Repository field is a picker, not an expression: you choose a concrete repository when you build the workflow and it cannot be computed at run time. The picker lists only repositories where the connected account holds the admin role, because registering a webhook needs admin on the repository. Repository pickers on Bitbucket actions are the other shape: no role filter, so they can offer repositories you only have read access to, but they fetch a single page. Neither list is a subset of the other, and in a workspace with many repositories the action picker is often the shorter one.

Repository events

• bitbucket/repo-push fires when commits are pushed to a branch or tag.
• bitbucket/repo-fork fires when someone forks the repository. The payload carries the original repository under repository and the new fork under fork.
• bitbucket/repo-updated fires when the repository's name, description, website or language changes under Repository details. changes carries an old and new pair per changed field.
• bitbucket/commit-comment-created fires when someone comments on a commit.
• bitbucket/commit-status-created fires when a build system, CI tool or other vendor creates a build status against a commit.
• bitbucket/commit-status-updated fires when one of those updates an existing build status, for example when a build moves from INPROGRESS to SUCCESSFUL.

Pull request events

• bitbucket/pull-request-created fires when a pull request is opened.
• bitbucket/pull-request-updated fires when a user updates a pull request. Atlassian does not publish which edits count, so check a real delivery before you branch on a specific field.
• bitbucket/pull-request-push fires when Bitbucket reports a push on an open pull request. Atlassian lists the event but publishes no payload reference for it, so treat its body as the shared pull-request shape and check a real delivery before you map deep fields.
• bitbucket/pull-request-approved fires when a reviewer approves.
• bitbucket/pull-request-unapproved fires when a reviewer withdraws their approval.
• bitbucket/pull-request-changes-requested fires when a reviewer sets Request Changes.
• bitbucket/pull-request-changes-request-removed fires when a reviewer clears Request Changes.
• bitbucket/pull-request-merged fires on merge. Bitbucket's wire event for a merge is pullrequest:fulfilled.
• bitbucket/pull-request-declined fires on decline. Bitbucket's wire event for a decline is pullrequest:rejected.
• bitbucket/pull-request-comment-created fires on a new comment, including inline comments and replies.
• bitbucket/pull-request-comment-updated fires when a comment is edited. Bitbucket sends only the first of several quick edits to the same comment, so the payload you receive can carry text the author has since changed again.
• bitbucket/pull-request-comment-deleted fires when a comment is deleted.
• bitbucket/pull-request-comment-resolved fires when a comment thread is resolved.
• bitbucket/pull-request-comment-reopened fires when a resolved thread is reopened.

Workspace events

These four fire for every repository in the workspace, including ones created after you publish, so they carry no Repository field. TaskJuice registers one workspace-level webhook for them, separately from the per-repository hooks above.

• bitbucket/repo-created fires when a repository is created anywhere in the connected workspace.
• bitbucket/repo-deleted fires when a repository is deleted anywhere in the connected workspace.
• bitbucket/repo-imported fires when a repository import finishes anywhere in the connected workspace.
• bitbucket/repo-transferred fires when a repository transfer involving the connected workspace is accepted. Bitbucket documents the event as “Transfer accepted” and does not publish its payload, so check a real delivery before branching on which workspace the repository object names.

How deliveries are verified

Bitbucket computes an HMAC-SHA256 over the raw request body using the webhook's secret and sends the hex digest in the X-Hub-Signature header, formatted as sha256=<digest>. TaskJuice recomputes that digest on every inbound POST and rejects anything that does not match, so a forged or altered delivery never starts a run.

A webhook with no secret set is delivered with no X-Hub-Signature header at all. TaskJuice refuses those outright rather than trusting them, which is why the manual fallback below insists on the secret.

If registration does not finish

A failed attempt does not surface straight away. The panel keeps showing "Setting up Bitbucket…" while TaskJuice is still retrying, and a message replaces it only after repeated failures. The three worth knowing in advance — plus the workspace-owner message above, which only the four workspace events can produce:

• "Bitbucket rejected the connection. Reconnect your Bitbucket account, then republish." The OAuth grant was revoked, or your Bitbucket OAuth consumer does not carry the Webhooks: Read and write permission. Tick it on the consumer in Bitbucket, then reconnect Bitbucket under Connections and republish.
• "Bitbucket did not confirm the registration. Registration retries automatically — no action needed." Bitbucket did not answer in time. TaskJuice keeps retrying on its own, backing off between attempts, and the panel clears when it succeeds.
• "Automatic setup for Bitbucket stopped after repeated failures, and its triggers may not be firing. Contact support." Everything else ends here, including a repository that has hit Bitbucket's limit of 50 webhooks. TaskJuice does not name that limit for Bitbucket, on purpose: the panel only reports a webhook cap for providers whose cap response has been captured and declared, and Bitbucket's has not. If you see this message, check the webhook count under Repository settings first, free a slot, and republish. Read the message at face value while you do — the repository's webhook may never have been created, in which case none of its Bitbucket triggers are receiving anything.

What happens when you unpublish or disconnect

Unpublishing a trigger leaves the Bitbucket webhook in place and narrows it to the events your remaining published workflows still need. The panel says so: "This trigger is unpublished. Your Bitbucket setup is kept, so republishing starts events again straight away." The registration is kept for 90 days, so a republish inside that window costs no new secret and no re-registration. After 90 days it is deleted — from the repository for a per-repository trigger, and from the workspace for one of the four workspace events.

Disconnecting the Bitbucket connection is different: it tears the webhooks down. TaskJuice deletes each one it registered, and if Bitbucket cannot be reached it keeps retrying on its own, backing off between attempts.

Set up the webhook yourself

Use this only when the connected account cannot be granted the webhook scope. Everything above stops applying: nothing is registered, narrowed or torn down for you.

1. Copy the delivery URL and secret from TaskJuice

   The trigger shows both. The secret is generated for you and shown so you can paste it.

2. Add the webhook in Bitbucket

   For a per-repository trigger, open Repository settings, then Webhooks, then Add webhook. For the four workspace events, open Workspace settings, then Webhooks — those events are not offered on a repository hook at all, so a repository webhook for them can never fire. Point the hook at the delivery URL and tick the events matching the triggers you published.

3. Paste the secret into the Secret field

   Paste the exact value TaskJuice showed you. A webhook saved without a secret is delivered unsigned, and TaskJuice rejects unsigned deliveries.

Bitbucket does not display a webhook's secret again after you save it, and TaskJuice cannot read a secret it did not set. If the two ever fall out of step, every delivery fails verification: replace the value on both sides rather than guessing which one drifted.

Actions

Repositories

• bitbucket/list-repositories lists repositories in the connected workspace.
• bitbucket/get-repository retrieves a single repository by slug.

Pull requests

• bitbucket/list-pull-requests lists pull requests on a repository, filtered by state.
• bitbucket/get-pull-request retrieves one pull request by its numeric ID.
• bitbucket/create-pull-request opens a pull request between two branches.
• bitbucket/update-pull-request changes an open pull request's title, description or destination branch. Only open pull requests can be changed.
• bitbucket/approve-pull-request approves a pull request as the connected account.
• bitbucket/merge-pull-request merges an open pull request. A conflict error means one of the branches moved while Bitbucket was merging; the run stops rather than retrying, so re-run the workflow once the branch settles.
• bitbucket/decline-pull-request declines an open pull request without merging it.
• bitbucket/create-pull-request-comment posts a comment, or a threaded reply when you supply a parent comment ID.

Commits and build statuses

• bitbucket/list-commits lists commits in reverse chronological order, optionally limited to one branch or tag and to commits touching a path.
• bitbucket/get-commit retrieves a single commit by hash.
• bitbucket/create-commit-build-status creates or overwrites a build status on a commit. Posting the same key again replaces the existing status, which is how a build moves from INPROGRESS to SUCCESSFUL.

Branches and tags

• bitbucket/list-branches lists a repository's open branches.
• bitbucket/create-branch creates a branch pointing at an existing commit. The name must not carry a refs/heads prefix.
• bitbucket/list-tags lists the tags on a repository, newest first by default.

Workspace

• bitbucket/list-workspace-members lists the members of the connected workspace.

More repository actions

• bitbucket/create-repository creates a repository in the connected Bitbucket workspace under the slug you supply.
• bitbucket/list-file-conflicts lists the files that would conflict when merging two revisions of a Bitbucket repository.
• bitbucket/list-repository-watchers lists the accounts watching a Bitbucket repository.
• bitbucket/update-repository updates the settings of a Bitbucket repository. Bitbucket applies the change immediately and offers no undo for the previous settings.

More branch and tag actions

• bitbucket/create-tag creates a tag on a commit in a Bitbucket repository.
• bitbucket/delete-branch deletes a branch from a Bitbucket repository. Bitbucket offers no undo, so unmerged commits on that branch become unreachable.
• bitbucket/delete-tag deletes a tag from a Bitbucket repository. Bitbucket offers no undo for a deleted tag.
• bitbucket/get-branch reads a single branch in a Bitbucket repository, including the commit it points at.
• bitbucket/get-tag reads a single tag in a Bitbucket repository, including the commit it points at.
• bitbucket/list-refs lists every branch and tag in a Bitbucket repository in one paginated read.

Source files

• bitbucket/create-commit-from-files creates a commit on a Bitbucket repository by uploading file contents. Supply a Files object whose keys are repository paths and whose values are the new file contents.
• bitbucket/get-source reads a file or directory in a Bitbucket repository at a given commit. A directory returns a paginated listing; a file returns its contents as text unless the format parameter asks for metadata.
• bitbucket/list-source-root lists the files and directories at the root of the main branch of a Bitbucket repository.

File history

• bitbucket/list-file-history lists the commits that modified a file in a Bitbucket repository, walking back from a starting commit.

Forks

• bitbucket/fork-repository forks a Bitbucket repository into a workspace, optionally under a different name.
• bitbucket/list-repository-forks lists the repositories forked from a Bitbucket repository.

Diffs and patches

• bitbucket/get-diff returns the raw unified diff between two revisions of a Bitbucket repository, as plain text.
• bitbucket/get-diff-stat returns the per-file added and removed line counts between two revisions of a Bitbucket repository.
• bitbucket/get-patch returns the raw git patch between two revisions of a Bitbucket repository, as plain text.
• bitbucket/get-pull-request-diff returns the raw unified diff of a pull request on a Bitbucket repository, as plain text.
• bitbucket/get-pull-request-diff-stat returns the per-file added and removed line counts for a pull request on a Bitbucket repository.
• bitbucket/get-pull-request-patch returns the raw git patch of a pull request on a Bitbucket repository, as plain text.

More commit actions

• bitbucket/approve-commit records the connected Bitbucket account as having approved a commit.
• bitbucket/create-commit-comment adds a comment to a commit in a Bitbucket repository, optionally anchored to a line in the diff.
• bitbucket/delete-commit-comment deletes a comment from a commit in a Bitbucket repository.
• bitbucket/get-commit-build-status reads a single build status on a commit in a Bitbucket repository, by the key the reporting system used.
• bitbucket/get-commit-comment reads a single comment on a commit in a Bitbucket repository.
• bitbucket/get-merge-base finds the common ancestor commit of two revisions in a Bitbucket repository.
• bitbucket/list-commit-comments lists the comments left on a commit in a Bitbucket repository.
• bitbucket/list-commit-statuses lists the build statuses reported against a commit in a Bitbucket repository.
• bitbucket/list-commits-for-revision lists the commits reachable from a branch, tag or commit hash in a Bitbucket repository, newest first.
• bitbucket/list-pull-request-commits lists the commits included in a pull request on a Bitbucket repository.
• bitbucket/list-pull-requests-for-commit lists the pull requests in a Bitbucket repository that contain a given commit.
• bitbucket/unapprove-commit withdraws the connected Bitbucket account’s approval of a commit.
• bitbucket/update-commit-build-status updates an existing build status on a commit in a Bitbucket repository, for example moving it from in progress to successful.
• bitbucket/update-commit-comment rewrites the body of an existing comment on a commit in a Bitbucket repository.

Code insights

• bitbucket/create-code-insights-annotation adds one annotation to a code insights report on a commit in a Bitbucket repository. Bitbucket exposes only a bulk endpoint here, so this action sends a one-element array and writes a single annotation per call.
• bitbucket/create-or-update-code-insights-report creates a code insights report on a commit in a Bitbucket repository, or replaces the report already stored under that report id.
• bitbucket/delete-code-insights-annotation deletes a single annotation from a code insights report on a commit in a Bitbucket repository.
• bitbucket/delete-code-insights-report deletes a code insights report and all of its annotations from a commit in a Bitbucket repository.
• bitbucket/get-code-insights-annotation reads a single annotation on a code insights report on a commit in a Bitbucket repository.
• bitbucket/get-code-insights-report reads a single code insights report attached to a commit in a Bitbucket repository.
• bitbucket/list-code-insights-annotations lists the annotations attached to a code insights report on a commit in a Bitbucket repository.
• bitbucket/list-code-insights-reports lists the code insights reports attached to a commit in a Bitbucket repository.
• bitbucket/update-code-insights-annotation creates or replaces a single annotation on a code insights report on a commit in a Bitbucket repository.

More pull request actions

• bitbucket/delete-pull-request-comment deletes a comment from a pull request in a Bitbucket repository.
• bitbucket/get-pull-request-comment reads a single comment on a pull request in a Bitbucket repository.
• bitbucket/get-pull-request-merge-task-status polls the status of an asynchronous pull request merge in a Bitbucket repository, using the task id the merge returned.
• bitbucket/list-pull-request-activity lists the activity log of a single pull request in a Bitbucket repository, covering approvals, updates and comments.
• bitbucket/list-pull-request-comments lists the comments on a pull request in a Bitbucket repository, including inline diff comments.
• bitbucket/list-pull-request-conflicts lists the files that conflict between the source and destination branches of a pull request in a Bitbucket repository.
• bitbucket/list-pull-request-statuses lists the build statuses reported against the commits of a pull request in a Bitbucket repository.
• bitbucket/list-repository-pull-request-activity lists the activity log across every pull request in a Bitbucket repository, covering approvals, updates and comments.
• bitbucket/list-workspace-pull-requests-for-user lists the pull requests a given user has open across the connected Bitbucket workspace.
• bitbucket/reopen-pull-request-comment-thread reopens a resolved comment thread on a pull request in a Bitbucket repository.
• bitbucket/request-changes-on-pull-request records the connected Bitbucket account as requesting changes on a pull request, which blocks merging until it is withdrawn.
• bitbucket/resolve-pull-request-comment-thread marks a comment thread on a pull request in a Bitbucket repository as resolved.
• bitbucket/unapprove-pull-request withdraws the connected Bitbucket account approval of a pull request.
• bitbucket/update-pull-request-comment rewrites the body of a comment on a pull request in a Bitbucket repository.
• bitbucket/withdraw-changes-request-on-pull-request withdraws a change request the connected Bitbucket account previously made on a pull request.

Pull request tasks

• bitbucket/create-pull-request-task creates a task on a pull request in a Bitbucket repository, optionally attached to an existing comment.
• bitbucket/delete-pull-request-task deletes a task from a pull request in a Bitbucket repository.
• bitbucket/get-pull-request-task reads a single task on a pull request in a Bitbucket repository.
• bitbucket/list-pull-request-tasks lists the tasks on a pull request in a Bitbucket repository, including whether each one is resolved.
• bitbucket/update-pull-request-task updates a task on a pull request in a Bitbucket repository, for example marking it resolved.

Default reviewers

• bitbucket/add-project-default-reviewer adds a user to the default reviewers of a Bitbucket project, so repositories inheriting from it request their review automatically.
• bitbucket/add-repository-default-reviewer adds a user to the default reviewers of a Bitbucket repository, so new pull requests request their review automatically.
• bitbucket/get-project-default-reviewer checks whether a specific user is a default reviewer on a Bitbucket project, and returns their account.
• bitbucket/get-repository-default-reviewer checks whether a specific user is a default reviewer on a Bitbucket repository, and returns their account.
• bitbucket/list-effective-default-reviewers lists the default reviewers a Bitbucket repository actually applies, combining its own list with the ones inherited from its project.
• bitbucket/list-project-default-reviewers lists the users configured as default reviewers on a Bitbucket project.
• bitbucket/list-repository-default-reviewers lists the users configured as default reviewers on a Bitbucket repository.
• bitbucket/remove-project-default-reviewer removes a user from the default reviewers of a Bitbucket project.
• bitbucket/remove-repository-default-reviewer removes a user from the default reviewers of a Bitbucket repository.

Branch restrictions

• bitbucket/create-branch-restriction creates a branch restriction rule on a Bitbucket repository, such as requiring approvals before a branch can be merged.
• bitbucket/delete-branch-restriction deletes a branch restriction rule from a Bitbucket repository, removing the merge gate it enforced.
• bitbucket/get-branch-restriction reads a single branch restriction rule on a Bitbucket repository by its numeric rule id.
• bitbucket/list-branch-restrictions lists the branch restriction rules configured on a Bitbucket repository, optionally filtered by kind or branch pattern.
• bitbucket/update-branch-restriction updates an existing branch restriction rule on a Bitbucket repository; the rule kind itself cannot be changed.

Branching model

• bitbucket/get-effective-branching-model reads the branching model currently applied to a Bitbucket repository, after any project-level inheritance is resolved.
• bitbucket/get-project-branching-model reads the branching model a Bitbucket project passes down to the repositories that inherit from it.
• bitbucket/get-project-branching-model-settings reads the branching model configuration of a Bitbucket project, including which branch types it enables for inheriting repositories.
• bitbucket/get-repository-branching-model reads the branching model of a Bitbucket repository, including its development and production branches and branch types.
• bitbucket/get-repository-branching-model-settings reads the branching model configuration of a Bitbucket repository, including which branch types are enabled.
• bitbucket/update-project-branching-model-settings updates the branching model configuration of a Bitbucket project, which every repository inheriting from it then applies.
• bitbucket/update-repository-branching-model-settings updates the branching model configuration of a Bitbucket repository, changing which branch types are enabled and how they are named.

Inherited settings

• bitbucket/get-repository-override-settings reads which repository settings a Bitbucket repository overrides rather than inheriting from its project.
• bitbucket/update-repository-override-settings sets which repository settings a Bitbucket repository overrides rather than inheriting from its project. Turning an override off discards the repository-level values it was holding.

Deploy keys

• bitbucket/add-project-deploy-key installs an SSH public key as a deploy key on a Bitbucket project, granting whoever holds the matching private key access to its repositories.
• bitbucket/add-repository-deploy-key installs an SSH public key as a deploy key on a Bitbucket repository, granting whoever holds the matching private key access to it.
• bitbucket/delete-project-deploy-key removes a deploy key from a Bitbucket project, revoking the access it granted to the project’s repositories.
• bitbucket/delete-repository-deploy-key removes a deploy key from a Bitbucket repository, revoking the access it granted.
• bitbucket/get-project-deploy-key reads a single deploy key installed on a Bitbucket project.
• bitbucket/get-repository-deploy-key reads a single deploy key installed on a Bitbucket repository.
• bitbucket/list-project-deploy-keys lists the deploy keys installed on a Bitbucket project.
• bitbucket/list-repository-deploy-keys lists the deploy keys installed on a Bitbucket repository.
• bitbucket/update-repository-deploy-key replaces the public key or label of a deploy key installed on a Bitbucket repository.

Pipelines

• bitbucket/get-pipeline reads a single pipeline run on a Bitbucket repository, including its state, target and build number.
• bitbucket/get-pipeline-step reads a single step of a pipeline run on a Bitbucket repository, including its image, script and state.
• bitbucket/get-pipeline-step-container-log downloads the log of one container within a pipeline step on a Bitbucket repository. Bitbucket returns the log as a byte stream rather than JSON.
• bitbucket/get-pipeline-step-log downloads the build log of a pipeline step on a Bitbucket repository. Bitbucket returns the log as a byte stream rather than JSON.
• bitbucket/get-pipeline-step-test-report reads the test report summary of a pipeline step on a Bitbucket repository, including the pass, fail and skip counts.
• bitbucket/get-pipeline-test-case-reasons reads the failure output captured for a single test case in a pipeline step on a Bitbucket repository.
• bitbucket/list-pipeline-step-test-cases lists the individual test cases reported by a pipeline step on a Bitbucket repository.
• bitbucket/list-pipeline-steps lists the steps of a pipeline run on a Bitbucket repository, with the state of each one.
• bitbucket/list-pipelines lists the pipeline runs of a Bitbucket repository, filtered by branch, status, trigger type or creator.
• bitbucket/run-pipeline starts a pipeline on a Bitbucket repository against a branch, tag or commit, optionally selecting a custom pipeline and passing variables.
• bitbucket/stop-pipeline stops a running pipeline on a Bitbucket repository. A stopped run cannot be resumed; it has to be started again from the beginning.

Pipelines configuration

• bitbucket/get-pipelines-config reads whether Bitbucket Pipelines is enabled on a repository.
• bitbucket/set-build-number sets the build number Bitbucket Pipelines assigns to the next run of a repository.
• bitbucket/update-pipelines-config enables or disables Bitbucket Pipelines on a repository.

Pipeline schedules

• bitbucket/create-pipeline-schedule creates a pipeline schedule on a Bitbucket repository so a pipeline runs on a cron pattern.
• bitbucket/delete-pipeline-schedule deletes a pipeline schedule from a Bitbucket repository, stopping the scheduled runs it created.
• bitbucket/get-pipeline-schedule reads a single pipeline schedule on a Bitbucket repository, including its cron pattern and target.
• bitbucket/list-pipeline-schedule-executions lists the runs a pipeline schedule on a Bitbucket repository has produced, newest first.
• bitbucket/list-pipeline-schedules lists the pipeline schedules configured on a Bitbucket repository.
• bitbucket/update-pipeline-schedule enables or disables a pipeline schedule on a Bitbucket repository.

Repository pipeline variables

• bitbucket/create-repository-pipeline-variable creates a pipeline variable on a Bitbucket repository.
• bitbucket/delete-repository-pipeline-variable deletes a pipeline variable from a Bitbucket repository.
• bitbucket/get-repository-pipeline-variable reads a single pipeline variable on a Bitbucket repository. Values of variables not marked secured arrive in plaintext and are stored in workflow run data; secured variables arrive with an empty value.
• bitbucket/list-repository-pipeline-variables lists the pipeline variables set on a Bitbucket repository. Values of variables not marked secured arrive in plaintext and are stored in workflow run data; secured variables arrive with an empty value.
• bitbucket/update-repository-pipeline-variable updates a pipeline variable on a Bitbucket repository.

Deployments

• bitbucket/get-deployment reads a single deployment recorded by Bitbucket Pipelines, including its environment, state and the release it deployed.
• bitbucket/list-deployments lists the deployments Bitbucket Pipelines has recorded for a repository, newest first.

Environments and deployment variables

• bitbucket/create-environment creates a deployment environment on a Bitbucket repository so pipelines can deploy to it.
• bitbucket/create-environment-variable creates a deployment variable on an environment of a Bitbucket repository.
• bitbucket/delete-environment deletes a deployment environment from a Bitbucket repository, along with the deployment variables stored on it.
• bitbucket/delete-environment-variable deletes a deployment variable from an environment of a Bitbucket repository.
• bitbucket/get-environment reads a single deployment environment on a Bitbucket repository.
• bitbucket/list-environment-variables lists the deployment variables set on an environment of a Bitbucket repository. Values of variables not marked secured arrive in plaintext and are stored in workflow run data; secured variables arrive with an empty value.
• bitbucket/list-environments lists the deployment environments configured on a Bitbucket repository.
• bitbucket/update-environment submits a change to a deployment environment on a Bitbucket repository, such as altering its deployment restrictions.
• bitbucket/update-environment-variable updates a deployment variable on an environment of a Bitbucket repository.

Projects

• bitbucket/create-project creates a project in the connected Bitbucket workspace to group repositories under.
• bitbucket/delete-project deletes a project from the connected Bitbucket workspace. The project must hold no repositories, and the deletion cannot be undone.
• bitbucket/get-project reads a single project in the connected Bitbucket workspace.
• bitbucket/list-projects lists the projects in the connected Bitbucket workspace.
• bitbucket/update-project updates a project in the connected Bitbucket workspace, or creates it when no project carries that key.

Repository webhooks

• bitbucket/create-repository-webhook installs a webhook on a Bitbucket repository, pointing at a delivery URL you control.
• bitbucket/delete-repository-webhook removes a webhook from a Bitbucket repository. Do not target hooks whose description is "TaskJuice managed webhook — do not edit by hand" — those are provisioned by TaskJuice, and changing or deleting one stops your own Bitbucket triggers firing until TaskJuice restores it, which can take about five minutes.
• bitbucket/get-repository-webhook reads a single webhook installed on a Bitbucket repository.
• bitbucket/list-repository-webhooks lists the webhooks installed on a Bitbucket repository, including any TaskJuice provisions for you.
• bitbucket/update-repository-webhook updates a webhook installed on a Bitbucket repository, changing its URL, secret, active flag or event list. Do not target hooks whose description is "TaskJuice managed webhook — do not edit by hand" — those are provisioned by TaskJuice, and changing or deleting one stops your own Bitbucket triggers firing until TaskJuice restores it, which can take about five minutes.

Workspace webhooks

• bitbucket/create-workspace-webhook installs a workspace-wide webhook on the connected Bitbucket workspace. Only a workspace owner may do this.
• bitbucket/delete-workspace-webhook removes a webhook from the connected Bitbucket workspace. Do not target hooks whose description is "TaskJuice managed webhook — do not edit by hand" — those are provisioned by TaskJuice, and changing or deleting one stops your own Bitbucket triggers firing until TaskJuice restores it, which can take about five minutes.
• bitbucket/get-workspace-webhook reads a single webhook installed on the connected Bitbucket workspace.
• bitbucket/list-workspace-webhooks lists the webhooks installed on the connected Bitbucket workspace, including any TaskJuice provisions for you.
• bitbucket/update-workspace-webhook updates a webhook installed on the connected Bitbucket workspace, changing its URL, secret, active flag or event list. Do not target hooks whose description is "TaskJuice managed webhook — do not edit by hand" — those are provisioned by TaskJuice, and changing or deleting one stops your own Bitbucket triggers firing until TaskJuice restores it, which can take about five minutes.

Workspace pipeline variables

• bitbucket/create-workspace-pipeline-variable creates a pipeline variable on the connected Bitbucket workspace, visible to every repository in it.
• bitbucket/delete-workspace-pipeline-variable deletes a pipeline variable from the connected Bitbucket workspace.
• bitbucket/get-workspace-pipeline-variable reads a single pipeline variable on the connected Bitbucket workspace. Values of variables not marked secured arrive in plaintext and are stored in workflow run data; secured variables arrive with an empty value.
• bitbucket/list-workspace-pipeline-variables lists the pipeline variables set on the connected Bitbucket workspace. Values of variables not marked secured arrive in plaintext and are stored in workflow run data; secured variables arrive with an empty value.
• bitbucket/update-workspace-pipeline-variable updates a pipeline variable on the connected Bitbucket workspace.

Workspace, users and permissions

• bitbucket/get-current-user reads the Bitbucket account the connection authenticates as.
• bitbucket/get-current-user-workspace-permission reads the permission level the connected Bitbucket account holds on the connected workspace.
• bitbucket/get-user reads a public Bitbucket account by its account id or UUID.
• bitbucket/get-workspace reads the connected Bitbucket workspace, including its name, slug and privacy setting.
• bitbucket/get-workspace-member reads one member of the connected Bitbucket workspace, including their membership record.
• bitbucket/list-current-user-repository-permissions lists the permission the connected Bitbucket account holds on each repository in the connected workspace.
• bitbucket/list-current-user-workspaces lists the Bitbucket workspaces the connected account can reach, not only the one the connection is bound to.
• bitbucket/list-repository-permissions lists the permission every user holds on one repository in the connected Bitbucket workspace.
• bitbucket/list-workspace-permissions lists the permission every member holds on the connected Bitbucket workspace.
• bitbucket/list-workspace-repository-permissions lists every user-to-repository permission across the connected Bitbucket workspace.

Issues

• bitbucket/create-issue is dead surface. It called the native Bitbucket issue tracker, which no longer exists, so it fails on every workspace. Read the callout below before you touch it.

Known limitations

• Bitbucket's API limits are counted per Atlassian user, not per grant. Every OAuth grant the same Atlassian account authorizes draws on one hourly budget, so a busy workflow and a busy script authorized by the same account contend with each other. TaskJuice classifies a 429 as retryable and backs the step off before trying again.
• The six original list actions return one page; the newer ones page for you. bitbucket/list-branches, bitbucket/list-tags, bitbucket/list-commits and bitbucket/list-workspace-members ask Bitbucket for 100 items, and bitbucket/list-repositories and bitbucket/list-pull-requests take that endpoint's default page size, which is ten for repositories. Those six stop at the first page: their output carries Bitbucket's next link so you can tell there is more, but no input advances the page. Every list action added since pages through Bitbucket's page parameter instead, so it sweeps the whole result. Where you are on one of the six, narrow with the query and sort inputs, or call the endpoint yourself with the HTTP app.
• The two repository pickers do not list the same repositories. The trigger picker is admin-scoped, because only a repository administrator can register a webhook, and it pages deeply. The action picker is not role-scoped but fetches one page, so it can be the shorter of the two. Either can omit a repository the other offers.
• A repository holds at most 50 webhooks. TaskJuice spends exactly one of them however many per-repository Bitbucket triggers you publish, but other tools wired into the same repository share the budget, and an unpublished trigger keeps holding its slot for 90 days. The four workspace events do not touch that budget: they are served by one workspace-level webhook, registered once for the whole workspace.
• Unsigned deliveries are rejected. A webhook saved without a secret arrives with no signature, and TaskJuice refuses it. This is the single most common cause of a hand-made Bitbucket webhook delivering nothing.
• A merge Bitbucket answers asynchronously reads as a failure. bitbucket/merge-pull-request treats only a completed merge as success. On a very large pull request Bitbucket can accept the merge and finish it in the background, and the step reports an error even though the merge goes through. Check the pull request in Bitbucket before retrying.
• Deliveries carry no timestamp. Bitbucket signs the body and nothing else, so a signature proves where a delivery came from but not when. Treat Bitbucket triggers as at-least-once and make the workflow tolerate the same event arriving twice.
• The native issue tracker is gone. The issue endpoints and the issue:created, issue:updated and issue:comment_created webhook events went with it on 2026-08-20. Bitbucket still lists those event keys, but nothing produces them.

Next steps

• Connect an account walks the connection flow end to end.
• Trigger nodes covers what a trigger hands the rest of your workflow.
• No data coming in is where to start when a published trigger stays quiet.