Bitbucket

Before spending time looking for a Bitbucket panel in FlutterFlow's settings, it is important to confirm: there is no Bitbucket option in FlutterFlow's version control. FlutterFlow's GitHub sync (Settings & Integrations > GitHub > Connect GitHub) connects exclusively to GitHub repositories — it is a GitHub OAuth flow. You will not find a Bitbucket section anywhere in FlutterFlow's settings UI. Given this, you have two distinct use cases to choose between: Path 1 — Code mirroring for version control: You want your FlutterFlow project's Dart code in a Bitbucket repository. The method is to connect FlutterFlow to GitHub (using its native GitHub sync), then mirror the GitHub repository to Bitbucket. GitHub-to-Bitbucket mirroring can be done by scheduling a mirror sync in Bitbucket (Repository Settings > Repository details > Mirroring) or using a Bitbucket Pipelines job that pulls from GitHub. FlutterFlow pushes to GitHub; the mirror keeps Bitbucket in sync automatically. Path 2 — In-app Bitbucket data: You want to display Bitbucket data (repos, PRs, pipeline status) inside a FlutterFlow app screen. For this, you use the Bitbucket Cloud REST API at https://api.bitbucket.org/2.0/ via FlutterFlow's API Calls panel, with an App Password or Access Token for authentication. This guide focuses on Path 2 (the REST API approach), which is the more technically interesting integration. If you only need mirroring, set up FlutterFlow's GitHub sync first, then configure the Bitbucket mirror from the Bitbucket side — no FlutterFlow-specific configuration is needed for the mirror.

Bitbucket Cloud deprecated basic username/password authentication for API calls. Modern authentication uses App Passwords (tied to your Bitbucket user account) or Access Tokens (tied to a repository, workspace, or project). Do not use your real Bitbucket account password in any API Call or code — it will not work for API calls and is a serious security risk. To create an App Password, log into Bitbucket and go to your profile avatar (top-right) > Personal settings > App passwords > Create app password. Give it a descriptive name (e.g., 'FlutterFlow Dashboard'). Select the minimum scopes you need: for reading repositories, select 'Repositories: Read'; for reading pull requests, add 'Pull requests: Read'; for pipeline status, add 'Pipelines: Read'. Click Create and copy the generated password immediately — Bitbucket shows it only once. Alternatively, use a Repository Access Token (repository-scoped) or Workspace Access Token (workspace-scoped) from Repository Settings or Workspace Settings > Access tokens. Access Tokens are scoped to specific repositories or workspaces, which is safer than App Passwords (which cover your entire account). The token uses Bearer authentication in API calls: the Authorization header value is 'Bearer {token}' (for Access Tokens) or 'Basic {base64(username:appPassword)}' (for App Passwords). Do NOT put this token directly in FlutterFlow's API Call headers — it will be compiled into the Dart app and extractable by anyone who decompiles the APK. The next steps show how to proxy it through a backend function instead.

The Bitbucket App Password or Access Token is a secret credential — embedding it in FlutterFlow's API Call headers means it ships in the compiled Dart app. Anyone who decompiles the APK (a trivial process) can extract and reuse the token. Instead, the token must live in a server-side function that your FlutterFlow app calls. The function holds the token in an environment variable, calls the Bitbucket API on behalf of your app, and returns the result. The easiest backend for FlutterFlow is Firebase Cloud Functions (if you already use Firebase) or a Supabase Edge Function (if you use Supabase). Below is an example Firebase Cloud Function (Node.js) that accepts a workspace and repo name from your FlutterFlow app and returns the list of open pull requests from Bitbucket. Deploy it to Firebase, then add its HTTPS URL as the API Call base URL in FlutterFlow. In the Firebase Console, go to Project settings > Service accounts > Generate new private key if you need Firebase Admin SDK — but for this proxy, you only need the Bitbucket token as an environment variable set via Firebase CLI or the Firebase Console (Functions > your function > Configuration > Runtime environment variables). The function never exposes the token to the client. Jenkins users often also need a backend proxy because Jenkins typically lives on a private network. The same proxy pattern applies: the Cloud Function sits in the public cloud and forwards requests to the private Jenkins host, keeping credentials server-side.

1// Firebase Cloud Function — Bitbucket API proxy
2// Deploy via Firebase Console > Functions or Firebase CLI
3// Set BITBUCKET_TOKEN as an environment variable in Firebase Console
4
5const functions = require('firebase-functions');
6const https = require('https');
7
8exports.bitbucketProxy = functions.https.onRequest(async (req, res) => {
9  // Allow CORS for FlutterFlow web preview
10  res.set('Access-Control-Allow-Origin', '*');
11  res.set('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
12  res.set('Access-Control-Allow-Headers', 'Content-Type');
13  if (req.method === 'OPTIONS') {
14    res.status(204).send('');
15    return;
16  }
17
18  const token = process.env.BITBUCKET_TOKEN; // Set in Firebase env config
19  const workspace = req.query.workspace;
20  const repo = req.query.repo;
21  const endpoint = req.query.endpoint || 'pullrequests';
22
23  if (!workspace || !repo) {
24    res.status(400).json({ error: 'workspace and repo are required' });
25    return;
26  }
27
28  const bitbucketUrl =
29    `https://api.bitbucket.org/2.0/repositories/${workspace}/${repo}/${endpoint}?state=OPEN`;
30
31  try {
32    const response = await fetch(bitbucketUrl, {
33      headers: { Authorization: `Bearer ${token}` }
34    });
35    const data = await response.json();
36    res.status(response.status).json(data);
37  } catch (err) {
38    res.status(500).json({ error: err.message });
39  }
40});

With your backend proxy running, open FlutterFlow and click API Calls in the left navigation panel. Click + Add > Create API Group. Name it 'Bitbucket Dashboard' and set the Base URL to your Firebase Cloud Function URL (e.g., https://us-central1-{project}.cloudfunctions.net/bitbucketProxy). You do not add the Bitbucket token here — it lives in the Cloud Function. Under Headers, add 'Content-Type: application/json'. Inside the group, click + Add API Call. Name it 'GetPullRequests'. Set Method to GET. Leave the Path empty (your Cloud Function is the endpoint). Under the Variables tab, add the query parameters your proxy accepts: add variable 'workspace' (String) and 'repo' (String). These map to the ?workspace= and ?repo= query params the Cloud Function reads. Click the Response & Test tab. In the test inputs, enter your actual workspace slug and repo slug. Click Test — if your Cloud Function is deployed correctly, you see a 200 response with a JSON body containing the pull request list from Bitbucket. The response structure is Bitbucket's standard paginated format: { "values": [...], "pagelen": 10, "size": 15, "next": "https://..." }. Click Generate JSON Paths on the response. FlutterFlow extracts path patterns like $.values, $.values[0].title, $.values[0].state, $.values[0].author.display_name, $.values[0].links.html.href. Create a response variable for each field you want to display — these become the bindings for your ListView and Text widgets.

1// FlutterFlow API Call configuration reference
2{
3  "group_name": "Bitbucket Dashboard",
4  "base_url": "https://us-central1-{project}.cloudfunctions.net/bitbucketProxy",
5  "headers": {
6    "Content-Type": "application/json"
7  },
8  "calls": [
9    {
10      "name": "GetPullRequests",
11      "method": "GET",
12      "path": "",
13      "variables": [
14        { "name": "workspace", "type": "String" },
15        { "name": "repo", "type": "String" }
16      ],
17      "json_paths": {
18        "prList": "$.values",
19        "prTitle": "$.values[0].title",
20        "prState": "$.values[0].state",
21        "prAuthor": "$.values[0].author.display_name",
22        "nextPage": "$.next"
23      }
24    }
25  ]
26}

The Bitbucket Cloud REST API paginates all list responses. Unlike some APIs that use page number parameters, Bitbucket uses cursor-based pagination: the response body contains a 'next' field with the complete URL for the next page of results. If there are no more pages, 'next' is absent from the response. For a FlutterFlow dashboard listing pull requests, you have two practical approaches: Simple approach (no load-more button): Modify your proxy Cloud Function to accept a 'pagelen' parameter and set it to the maximum allowed (Bitbucket allows up to 100 items per page). For most small teams, 100 items is enough that pagination never becomes relevant. In your proxy, append ?pagelen=100 to the Bitbucket API request URL. This covers the majority of real-world use cases without building pagination UI. Load-more approach (for large workspaces): Add a response variable for the 'next' field (JSON path: $.next). Store this URL in a FlutterFlow page state variable. Add a 'Load More' button to the bottom of your ListView. Wire the button to an Action Flow that calls GetPullRequests again, but this time modifies the proxy call to forward the 'next' cursor URL directly to Bitbucket. Append the new page's values to the existing list state variable, then update the stored 'next' URL (or clear it when it is absent, hiding the 'Load More' button). For Pipeline status, add a second API Call in the same group — 'GetPipelineStatus' — pointing to /repositories/{workspace}/{repo}/pipelines?sort=-created_on&pagelen=5 in your proxy. This returns the 5 most recent Pipeline runs with their state (PASSED, FAILED, IN_PROGRESS) and the commit that triggered each run.

With your API Call configured and tested, bind the response data to FlutterFlow widgets. Add a ListView widget to the page. Set its data source to a Backend Query using your GetPullRequests API Call — pass the workspace and repo values from page variables (which you can set as constants for an internal tool or let the user select from a dropdown). Inside the ListView, add a Card or Container for each PR. Inside the card, add Text widgets for the PR title (bind to $.values[i].title), PR author (bind to $.values[i].author.display_name), target branch (bind to $.values[i].destination.branch.name), and a status badge (bind to $.values[i].state — values are 'OPEN', 'MERGED', 'DECLINED', 'SUPERSEDED'). Add a color conditional on the state field: green for MERGED, red for DECLINED, blue for OPEN. For Pipeline status, add a separate section or tab. Use another Backend Query with your GetPipelineStatus API Call. Bind the result field ($.values[i].state.result.name — values are 'SUCCESSFUL', 'FAILED', 'STOPPED') to a status indicator widget. Test your app in FlutterFlow's Run mode (click Run in the top toolbar) — the API Calls fire from your browser and return real Bitbucket data. Then test on a physical device or install via TestFlight/internal track to confirm the proxy call works from a mobile app context. If you are building a web app, test in a browser build to confirm the Cloud Function's CORS headers allow requests from your FlutterFlow web app's domain. If you need help wiring up a more complex Bitbucket dashboard, RapidDev's team builds FlutterFlow API integrations like this every week — free scoping call at rapidevelopers.com/contact.