GitHub

The native GitHub integration pushes FlutterFlow's generated Flutter/Dart code to a branch called `flutterflow` in a GitHub repository of your choice. To enable it, you must be on the Growth plan ($80/month) or higher — this is the most common surprise for founders who discover the feature is plan-gated after expecting it to be free. To connect: in the FlutterFlow toolbar, click the GitHub icon (it looks like the GitHub Octocat logo, in the top-right area of the editor), OR go to Settings & Integrations → GitHub. Click Connect GitHub — this opens a GitHub OAuth window asking you to authorize FlutterFlow's GitHub App for your GitHub account or organization. Grant the permissions. After authorization, you'll be prompted to select or create a repository. You can create a new repository directly from this screen, or point to an existing one. FlutterFlow will create the `flutterflow` branch if it doesn't exist. Once connected, a Push to GitHub button appears in the FlutterFlow toolbar. Click it to push your current project state to the `flutterflow` branch. The push happens in the cloud — no local git client needed. You can push as often as you like; each push reflects FlutterFlow's current generated code state. Note: FlutterFlow pushes only the generated code. Custom files you or a developer add inside the repository (on `main` or other branches) are invisible to FlutterFlow — it only manages the `flutterflow` branch.

This step is critical and skipping it leads to lost work. FlutterFlow's sync is one-way: FlutterFlow pushes to the `flutterflow` branch, and nothing from GitHub syncs back into FlutterFlow. Every time you click Push to GitHub, FlutterFlow overwrites the entire `flutterflow` branch with freshly generated code. This means: if you or a developer edit files directly on the `flutterflow` branch, those edits will be silently destroyed the next time anyone pushes from FlutterFlow. The correct workflow is: 1. FlutterFlow pushes generated code to the `flutterflow` branch. 2. On GitHub (github.com, in your browser — no terminal needed), open a Pull Request from `flutterflow` into `main` (or `develop`, or whatever your trunk branch is). 3. Merge the PR. Now `main` contains the latest generated code. 4. Your developer creates a new branch off `main` for their custom Dart additions and edits only there. 5. Developer work is merged back into `main` via a separate PR — never touching `flutterflow`. To create the PR on GitHub without a terminal: navigate to your repository → click Pull Requests → New pull request → select `flutterflow` as the compare branch and `main` as the base → click Create pull request → Merge. This workflow can be done entirely in the browser, no command line needed. If you use GitHub Actions for CI/CD, create a workflow that triggers on pushes to `main` (not `flutterflow`) so it runs after the merge, not immediately after FlutterFlow's raw push.

If you want to build GitHub-powered features inside your running FlutterFlow app — a repo browser, issue list, PR dashboard, or contributor viewer — you'll use the GitHub REST API as a FlutterFlow API Group. This is independent of the native push and works on any FlutterFlow plan. First, generate a fine-grained Personal Access Token on GitHub: go to GitHub → Settings → Developer Settings → Personal Access Tokens → Fine-grained tokens → Generate new token. Set the token's name (e.g., 'FlutterFlow App Read-Only'), set an expiration date, select the repositories the token should access (choose specific repos rather than 'All repositories' for least privilege), and select only the permissions your app needs. For a read-only repo browser: grant 'Contents: Read', 'Issues: Read', 'Metadata: Read'. Copy the generated token — you'll see it only once. In FlutterFlow, click API Calls in the left nav → + Add → Create API Group. Set: - **Group Name:** `GitHub` - **Base URL:** `https://api.github.com/` - **Headers:** - `Authorization`: `Bearer [App Constant: GITHUB_PAT]` - `Accept`: `application/vnd.github+json` - `X-GitHub-Api-Version`: `2022-11-28` Store the PAT as an App Constant (Settings & Integrations → App Settings → App Constants, constant name: `GITHUB_PAT`). The `Accept` header is important — without it, GitHub may return a different media type or an older API version. The `X-GitHub-Api-Version` header pins you to a specific stable API version, which prevents breaking changes from affecting your app.

1{
2  "api_group_name": "GitHub",
3  "base_url": "https://api.github.com/",
4  "headers": [
5    {
6      "name": "Authorization",
7      "value": "Bearer [App Constant: GITHUB_PAT]"
8    },
9    {
10      "name": "Accept",
11      "value": "application/vnd.github+json"
12    },
13    {
14      "name": "X-GitHub-Api-Version",
15      "value": "2022-11-28"
16    }
17  ]
18}

With the GitHub API Group created, add individual API Calls for the features your app needs. Here's how to build a repository list call: Inside the GitHub API Group, click + Add API Call: - **Call Name:** `GetRepoIssues` - **Method:** GET - **Endpoint (relative):** `repos/OWNER/REPO/issues?state=open&per_page=30` Replace `OWNER` and `REPO` with your organization/username and repository name, or add them as Variables so the call works dynamically across repos. To add a variable: click the Variables tab → + Add Variable, name it `owner`, then reference it in the endpoint as `repos/[owner]/[repo]/issues?state=open`. In the Response & Test tab, click Test to fire the request. If you get a 200, you'll see a JSON array of issue objects. Click + Add JSON Path to extract fields: - `issue_title` → `$[*].title` - `issue_number` → `$[*].number` - `issue_state` → `$[*].state` - `issue_author` → `$[*].user.login` - `issue_labels` → `$[*].labels[*].name` In your FlutterFlow UI, add a ListView, open its Backend Query panel, select the GitHub API Group and GetRepoIssues call, and bind the response fields to Text widgets inside the list item. Set a 30-second refresh interval if you want near-real-time issue updates. For write operations (creating issues, commenting, closing issues), the same API Group works, but use POST or PATCH methods, and consider routing those calls through a Firebase Cloud Function if your PAT has write scopes — write-capable PATs should never ship in a client binary that users can reverse-engineer.

1{
2  "call_name": "GetRepoIssues",
3  "method": "GET",
4  "endpoint": "repos/[owner]/[repo]/issues?state=open&per_page=30",
5  "variables": [
6    { "name": "owner", "type": "String" },
7    { "name": "repo", "type": "String" }
8  ],
9  "json_paths": [
10    { "name": "issue_title", "path": "$[*].title" },
11    { "name": "issue_number", "path": "$[*].number" },
12    { "name": "issue_state", "path": "$[*].state" },
13    { "name": "issue_author", "path": "$[*].user.login" }
14  ]
15}

GitHub webhooks allow your application to react to events — a developer pushing code, a PR being opened, an issue being closed — in near-real-time. However, FlutterFlow is a client-side Flutter app: it cannot listen on a port or receive incoming HTTP requests. There is no direct path from GitHub's webhook system into a FlutterFlow app. The solution is a two-step relay: **Step 1 — Firebase Cloud Function as the webhook receiver:** Deploy a Firebase Cloud Function with an HTTPS trigger. GitHub will send webhook POST requests to this function's URL. The function verifies the webhook signature (using the `x-hub-signature-256` header and your webhook secret), extracts the event payload, and writes the relevant data to a Firestore collection (e.g., `github_events`). **Step 2 — FlutterFlow reads from Firestore:** Your FlutterFlow app uses its native Firebase/Firestore integration to listen to the `github_events` collection with a real-time listener. When a new document appears (a new push, a new issue), the app's UI updates automatically — a new item in a list, a toast notification, a status badge change. This pattern is the standard approach for any webhook-to-FlutterFlow relay. The Cloud Function is the public-facing receiver; Firestore is the message bus; FlutterFlow is the read client. You never need to reconfigure FlutterFlow when GitHub's webhook fires — the Firestore real-time listener handles it. If you'd rather skip configuring Firebase Cloud Functions yourself, RapidDev's team builds FlutterFlow integrations like this every week — free scoping call at rapidevelopers.com/contact.

1// Firebase Cloud Function: receive GitHub webhooks
2// Deploy via Firebase Console → Functions
3const functions = require('firebase-functions');
4const admin = require('firebase-admin');
5const crypto = require('crypto');
6admin.initializeApp();
7
8exports.githubWebhook = functions.https.onRequest(async (req, res) => {
9  const secret = process.env.GITHUB_WEBHOOK_SECRET;
10  const sig = req.headers['x-hub-signature-256'];
11  const hmac = crypto
12    .createHmac('sha256', secret)
13    .update(JSON.stringify(req.body))
14    .digest('hex');
15  if (`sha256=${hmac}` !== sig) {
16    return res.status(401).send('Invalid signature');
17  }
18  const event = req.headers['x-github-event'];
19  const payload = req.body;
20  await admin.firestore().collection('github_events').add({
21    event,
22    repo: payload.repository?.full_name,
23    action: payload.action,
24    sender: payload.sender?.login,
25    timestamp: admin.firestore.FieldValue.serverTimestamp(),
26  });
27  res.status(200).send('OK');
28});