What Bitbucket's API can't do

As of 18 October 2026

Source Pocket can only do what Bitbucket Cloud's public REST API allows. Some things you can do on bitbucket.org have no API, and a few API calls behave in ways you would not guess. Each entry says what you would expect, what Bitbucket does, and what the app does instead.

We checked these against Atlassian's published API description and documentation, and tested several against real workspaces. Bitbucket changes over time; when an entry here stops being true, we will update the page.

Starting a manual step

What you would expect: A run that pauses on a manual step, such as a deploy waiting for approval, could be started from the app, the same way bitbucket.org shows a Run button.
What Bitbucket does: The public API has no way to start, resume, or re-run a manual or paused step. We checked Atlassian's published API description on 18 October 2026: 175 paths, none for this. The Run button on bitbucket.org calls an internal endpoint instead. When we tested that endpoint on 18 October 2026 against a real paused run, it rejected an API token with HTTP 401, whether the token was sent as Basic or Bearer authentication. It needs a signed-in browser session.
What Source Pocket does: The run shows which step it is waiting on and opens the run on bitbucket.org in an in-app browser, where you tap Run. Source Pocket cannot see that browser session. How the hand-off works.

The feature request is BCLOUD-20050, "API to trigger a manual or paused step in a pipeline". It has been open since 3 April 2020, has the status Gathering Interest, and had 120 votes when we checked. If you want this in Source Pocket, sign in to Atlassian's issue tracker and vote for it. A second request, BCLOUD-20992, was closed as a duplicate of it in 2023.

Stopping a run that is waiting on a manual step

What you would expect: Stopping a paused run ends it, or the request fails.
What Bitbucket does: The stop request returns 204 No Content, the normal success reply, and nothing changes: the run stays in progress and paused. Atlassian describes this state as one where all automatic steps have run and a manual step is still waiting, so there is nothing running to stop.
What Source Pocket does: Hides Stop on a run that is only waiting on a manual step, so the app never tells you a run was stopped when it was not. The bitbucket.org hand-off is offered instead.

Re-running a pipeline

What you would expect: Re-run a finished pipeline with the same settings, or re-run only its failed steps, as bitbucket.org offers.
What Bitbucket does: The API has no re-run and no "rerun failed steps". The only way to run again is to trigger a new pipeline, which gets a new build number. Secured variable values are never returned by the API; Bitbucket returns an empty value in their place.
What Source Pocket does: Re-run starts a new run on the same ref. For a custom pipeline it opens the trigger form with the ref and pipeline filled in and asks for variables again, because a secured value it cannot read back would otherwise be lost without warning. Failed-steps-only re-runs are not offered. See Re-run.

Sources: Bitbucket REST API description; View your pipeline (the bitbucket.org re-run options).

Listing a custom pipeline's variables

What you would expect: An endpoint that lists the variables a custom pipeline accepts, so a form can show the right fields.
What Bitbucket does: There is none. The variables are only declared in bitbucket-pipelines.yml.
What Source Pocket does: Reads bitbucket-pipelines.yml at the branch, tag, or commit you pick and builds the form from it. If the file cannot be read, you can still run the default pipeline or type a pipeline name and add variables by hand.

Notifications and the Inbox

What you would expect: A list of your notifications, as GitHub, GitLab, and Gitea provide, and a way to find every pull request waiting for your review.
What Bitbucket does: Bitbucket Cloud has no notifications API. There is also no endpoint for "pull requests I am reviewing" across repositories; it has to be asked repository by repository.
What Source Pocket does: The Inbox is meant to be fed by the push relay, which receives Bitbucket's webhooks. You choose how it runs: our hosted relay, a relay you host yourself, or no relay. With no relay, the app polls your watched repositories, the Inbox shows review requests and failed runs from those repositories only, it marks that history as partial, and done or snoozed state stays on your device. How the relay works.

The hourly request limit

What you would expect: An app that shows a running pipeline updates every few seconds.
What Bitbucket does: Bitbucket allows each user 1,000 requests per hour to repository endpoints, counted over a rolling hour, and every tool using your Atlassian account shares that allowance. Higher limits, up to 10,000, apply only to workspace, project, or repository access tokens in Standard or Premium workspaces with 100 or more paid users. Refreshing one run and its steps every 5 seconds would use 720 requests an hour by itself. Source: API request limits.
What Source Pocket does: Every screen that refreshes on its own uses the intervals below, chosen so the screens you can see at once stay under the limit with room for what you do by hand. The busiest case, an iPad showing a run list, a run, and a running log side by side, comes to 870 requests an hour. Home with 20 watched repositories peaks at 840.

Refresh intervals in Source Pocket
Screen	Refreshes	Requests each time
Run detail	Every 20 seconds while the run is active	2 (the run and its steps)
Step log	Every 8 seconds while the step runs, slowing to every 30 seconds while no new output arrives	1 while output arrives, 2 while it is quiet
Run list	Every 60 seconds while a run is active, every 5 minutes otherwise	1
Home	Run lists every 2 minutes while something is running, every 10 minutes otherwise; pull requests every 10 minutes	1 per watched repository for runs, 2 per repository for pull requests

If Bitbucket still answers that the limit is reached, screens that refresh on their own keep showing what they have and wait before trying again: as long as Bitbucket asks, or at least a minute. An action you take by hand shows "The provider is limiting requests."

This is why updates are not real time without the relay. With the push relay, Bitbucket's webhooks tell the relay when something happens, which costs nothing against your hourly allowance.

Step-by-step Live Activities

What you would expect: A Live Activity on the Lock Screen that moves from step to step as Bitbucket sends events.
What Bitbucket does: Pipelines posts one commit status for the whole pipeline, not one per step, and a commit status has only three states: in progress, successful, and failed. The pipeline trace webhook has step detail, but Bitbucket sends it only when the run has finished. No webhook reports a step starting or ending. Sources: Event payloads; Pipelines traces via webhooks.
What Source Pocket does: Step progress has to come from asking Bitbucket about the run, which counts against the hourly limit, so webhooks can only mark the start and the end of a run. Today a tracked run's Live Activity updates each time its run detail refreshes in the app, every 20 seconds.

Signing in through the browser

What you would expect: Tap "Sign in with Bitbucket", approve in the browser, and come back signed in, as most mobile apps do with OAuth and PKCE.
What Bitbucket does: Bitbucket Cloud does not support PKCE, the part of OAuth designed for apps that cannot keep a secret. Exchanging the sign-in code for a token requires the app's client secret, and a secret shipped inside a phone app can be extracted. Atlassian's developer terms also forbid embedding those credentials in open-source projects. The request for PKCE, BCLOUD-23469, is open with the status Gathering Interest. OAuth scopes are also fixed on the registered app, so a user cannot grant fewer.
What Source Pocket does: Signs in with an Atlassian API token you create, with scopes you choose. Browser sign-in needs a small server that holds the secret and does the exchange; until that exists, API tokens are the way in. Create a token.

Sources: Use OAuth on Bitbucket Cloud; Atlassian Developer Terms.

App passwords

What you would expect: Older Bitbucket guides tell you to create an app password.
What Bitbucket does: App passwords were removed on 28 July 2026 and return HTTP 401. API tokens replace them. Each API token needs an expiry date no more than a year away, and its scopes cannot be changed after it is created.
What Source Pocket does: Does not accept app passwords. When a token expires, create a new one and add the account again. Sources: Atlassian's announcement; Bitbucket Cloud changelog; API tokens.

Bitbucket issues

What you would expect: Repository issues from Bitbucket's built-in tracker.
What Bitbucket does: Atlassian removed the built-in issue tracker and its API on 20 August 2026. Source: Bitbucket Cloud changelog.
What Source Pocket does: Has no issues section for Bitbucket accounts. Issue tracking for Bitbucket repositories now lives in Jira, so issues are Jira links.

Not yet confirmed

We could not settle these from Atlassian's documentation or our own tests yet. The app is built to cope either way.

Waiting time after the rate limit. Atlassian's documentation does not describe the response when the limit is reached, or whether it says how long to wait. When no wait is given, the app waits a minute.
How long step logs are kept. One log from June 2025 no longer existed in October 2026 while its run was still listed. We found no published retention period.
Token expiry warnings. We have not found a way to read an API token's expiry date through the API, so the app may not be able to warn you before a token expires.
The scope Bitbucket checks when you trigger a pipeline. Atlassian's API description and scope text disagree. The scope list on the getting started page includes both read and write for pipelines, which covers either.