CircleCI

Log in to your CircleCI account at app.circleci.com. Click your profile avatar in the bottom-left corner and choose User Settings. In the left sidebar of the settings page, click Personal API Tokens. Click the Create New Token button, give it a descriptive name like 'FlutterFlow Ops Dashboard', and click Add API Token. CircleCI will display the token value exactly once. Copy it immediately and store it in a password manager or secure notes application—you will not be able to view the full token again. If you lose it, you will need to revoke and create a new one. Understand the scope of this token: a CircleCI personal API token grants the same permissions as your user account. It can read pipeline data, trigger builds, cancel builds, and access environment variables (depending on project permissions). This is a broad-scope credential. For a FlutterFlow app, you will configure it in the API Group header at build time—this is safer than hardcoding it in Dart code, but it is still a client-side configuration. Consider what your app is distributing: if this is a private internal tool used only by your team, the API Group header approach is acceptable. If you were building a consumer app, you would need a backend proxy. Also note your project slug. In CircleCI, go to a project, look at the URL in your browser—it will look like app.circleci.com/pipelines/github/mycompany/my-backend. The portion after /pipelines/ is your base, but the API expects the format gh/mycompany/my-backend (replace 'github' with 'gh', or 'bitbucket' with 'bb'). This format difference is the source of countless 404 errors.

In FlutterFlow, click API Calls in the left navigation panel. Click + Add and choose Create API Group. Name it CircleCI and set the Base URL to https://circleci.com/api/v2. Do not include a trailing slash. With the CircleCI group selected, go to the Headers tab. Add a header named Circle-Token with your personal API token as the value. This is the authentication method CircleCI's v2 API expects. Alternatively, CircleCI also accepts the token as a Bearer token in an Authorization header, but the Circle-Token approach is more explicit and matches CircleCI's own documentation examples for API key auth. Also add an Accept header with value application/json to ensure responses come back in JSON format rather than XML. This header configuration is shared by every API Call you add inside this group, so you configure authentication once and every subsequent call inherits it automatically. Click Save. One clarification that prevents a lot of confusion: CircleCI personal API tokens are tied to your personal account, not a specific project. The token can access any project you have permission to view in CircleCI. This is convenient for a dashboard spanning multiple repos, but it also means the token is a sensitive credential—anyone who obtains it can read your pipeline data and, through the POST endpoints, trigger builds that consume your build minutes.

1{
2  "group_name": "CircleCI",
3  "base_url": "https://circleci.com/api/v2",
4  "headers": {
5    "Circle-Token": "YOUR_CIRCLECI_PERSONAL_API_TOKEN",
6    "Accept": "application/json"
7  }
8}

Inside the CircleCI API Group, add your first API Call. Click + Add API Call, name it Get Pipelines, set method to GET, and endpoint to /project/{project-slug}/pipeline. Go to the Variables tab and add a String variable named project_slug. In the endpoint field, it will be referenced as {{ project_slug }}. Optionally add an integer variable named page_token for pagination, though for an initial dashboard you can leave it out and let CircleCI default to the most recent 20 pipelines. Add a second API Call named Get Pipeline Workflows with endpoint /pipeline/{pipeline_id}/workflow. Add a String variable named pipeline_id. Add a third API Call named Get Workflow Jobs with endpoint /workflow/{workflow_id}/job. Add a String variable named workflow_id. For the trigger call (optional), add a fourth API Call named Trigger Pipeline, set method to POST, endpoint /project/{project-slug}/pipeline. Add the project_slug variable. On the Body tab, set content type to JSON and add a body of { "branch": "{{ branch_name }}" } with a branch_name variable. Add this body raw as: {"branch": "{{ branch_name }}"}. Test the Get Pipelines call: go to Response & Test, type your project slug in the variable field (e.g., gh/mycompany/my-backend) and click Send. A 200 response returns an items array with pipeline objects. A 404 almost always means the project-slug format is wrong—check that you used gh/ or bb/ prefix, not just the repo name. A 401 means the Circle-Token header value has an error. Click Generate JSON Paths. Key paths: $.items[:].id (pipeline ID for chaining), $.items[:].state (running/failing/errored), $.items[:].vcs.branch, $.items[:].created_at.

1// GET /project/{project-slug}/pipeline — example response (partial)
2{
3  "next_page_token": null,
4  "items": [
5    {
6      "id": "abc-123-def-456",
7      "errors": [],
8      "project_slug": "gh/mycompany/my-backend",
9      "updated_at": "2026-07-09T10:00:00Z",
10      "number": 1042,
11      "state": "created",
12      "created_at": "2026-07-09T09:58:00Z",
13      "trigger": { "type": "webhook" },
14      "vcs": {
15        "branch": "main",
16        "revision": "a1b2c3d",
17        "commit": { "subject": "fix: update payment handler" }
18      }
19    }
20  ]
21}
22
23// GET /workflow/{workflow_id}/job — example response (partial)
24{
25  "items": [
26    {
27      "id": "job-uuid",
28      "name": "test-unit",
29      "status": "success",
30      "started_at": "2026-07-09T09:58:30Z",
31      "stopped_at": "2026-07-09T10:01:00Z",
32      "type": "build"
33    }
34  ]
35}

Create a Data Type named CIPipeline with fields: id (String), number (Integer), state (String), branch (String), createdAt (String), commitMessage (String). Also create a WorkflowStatus Data Type with: id (String), name (String), status (String). On your CI dashboard screen, add a ListView widget. In the page's Action Flow (On Page Load), trigger a Backend/API Call to Get Pipelines, passing your project slug as the project_slug variable. Bind the ListView to the $.items array of the response. Inside each ListView item, add a Container for the pipeline card. Add Text widgets for: pipeline number (bound to $.items[:].number), branch name ($.items[:].vcs.branch), commit message ($.items[:].vcs.commit.subject, may be null—handle gracefully), and created date. For the status color, set the Container's background or left border color with a Conditional Expression. The workflow status (fetched separately via Get Pipeline Workflows) is the most meaningful indicator. For a simplified dashboard using only pipeline state from the first call: if state equals 'errored', use red; if state equals 'created', use blue; otherwise use grey. For the trigger button: add a Button widget below the list or in the app bar. In the Action Flow Editor, add an API Call action pointing to Trigger Pipeline. Pass your project_slug and a hardcoded branch value (e.g., 'main'). Before the API Call action, add a Confirm Dialog action (under Alerts & Notifications) that shows 'Trigger a new build on main branch? This will consume CI build minutes.' so users can't accidentally fire real builds. After a successful trigger, add a Show Snack Bar action with 'Build triggered!' and re-trigger the Get Pipelines call to refresh the list. Use Conditional Visibility to show the trigger button only to authorized users—for example, only show it if the logged-in user's email matches an admin email list stored in your FlutterFlow app state.

For a richer detail screen, let users tap a pipeline card to see its workflows and jobs. Create a Pipeline Detail screen with a pipeline_id page parameter (String). On page load, call Get Pipeline Workflows passing pipeline_id as the pipeline_id variable. The response returns a list of workflows—bind these to a nested ListView showing workflow name and status. For each workflow, tapping it navigates to a Job List screen that calls Get Workflow Jobs with the workflow_id. This gives you a full three-level drill-down: pipeline → workflow → individual jobs. Job statuses ('success', 'failed', 'running', 'blocked') are highly actionable—a 'failed' job on a test step tells your team exactly what broke. Handling errors: the two most common API errors are 404 (wrong project-slug format) and 429 (rate limit). CircleCI applies per-token API rate limits—verify current limits in CircleCI's documentation. For the trigger endpoint (POST), each successful call spawns a real pipeline that consumes build minutes. If your team's FlutterFlow app accidentally fires many trigger calls (e.g., a user rapidly tapping the button), you could exhaust your monthly build minute quota. Implement a 30-second cooldown on the trigger button using FlutterFlow's app state: record the last trigger timestamp and disable the button if less than 30 seconds have elapsed since the last tap. For 401 errors on the Circle-Token header: double-check that the token value has no leading or trailing spaces in FlutterFlow's header configuration. Token values are case-sensitive. Remember the key message for your users: CircleCI does not build your FlutterFlow project. This integration monitors and triggers CI pipelines for backend/web code that CircleCI already knows about. FlutterFlow's own build pipeline (and optional GitHub export) is independent.