GitLab

GitLab Personal Access Tokens are the simplest auth method for Bubble integrations. They're generated in your GitLab user settings and can be scoped to specific permissions. Log in to your GitLab account at gitlab.com. Click your profile avatar in the top-right corner and select 'Edit profile' from the dropdown. In the left sidebar, click 'Access Tokens'. Click 'Add new token'. Fill in the token form: - Token name: 'Bubble Dashboard Integration' (something descriptive) - Expiration date: Set an appropriate expiry date (GitLab now requires an expiry on all tokens for security). A 1-year expiry is common for long-lived integrations; set a reminder to rotate the token before it expires. - Select scopes: check 'api' for full read/write API access. If you only need a read-only dashboard, check 'read_api' instead — this is safer for display-only Bubble apps. Click 'Create personal access token'. The token is displayed ONCE — copy it immediately and store it somewhere safe (a password manager). GitLab will never show this token again. For production Bubble apps with multiple users or organizational use, consider a Project Access Token (GitLab Premium) which is scoped to a single project rather than your entire account. For free-tier GitLab, Personal Access Tokens are the available option.

Open your Bubble app editor. Click the Plugins tab in the left sidebar. If the API Connector is not installed, click Add plugins, search for 'API Connector' (by Bubble), and install it. Return to Plugins → API Connector. Click Add another API. Set the name to 'GitLab'. In the Shared headers section, click Add a shared header: - Key: `PRIVATE-TOKEN` - Value: paste your GitLab Personal Access Token - Check the 'Private' checkbox on this header This is the critical difference from most other API integrations: GitLab uses `PRIVATE-TOKEN` as the header name — not `Authorization: Bearer`. Using `Authorization` will result in 401 Unauthorized responses on all calls. Base URL for calls: `https://gitlab.com/api/v4` If you're using a self-hosted GitLab instance (GitLab installed on your own server), the base URL is different: `https://{your-gitlab-host}/api/v4`. For example, if your company's GitLab is at gitlab.yourcompany.com, the base URL is https://gitlab.yourcompany.com/api/v4. Add a second optional non-private header: - Key: `Content-Type` - Value: `application/json` Save the API group configuration.

1{
2  "API Name": "GitLab",
3  "Shared Headers": {
4    "PRIVATE-TOKEN": "<private>",
5    "Content-Type": "application/json"
6  },
7  "Base URL": "https://gitlab.com/api/v4"
8}

Add GET calls for the three core data types you'll display in the Bubble dashboard. You'll need your GitLab project's numeric ID — find it in your GitLab project under Settings → General → Project ID (shown below the project name). Call 1 — Get Pipelines: - Click Add another call in the GitLab API group - Name: 'Get Pipelines' - Method: GET - URL: `https://gitlab.com/api/v4/projects/{project_id}/pipelines` - Add a URL parameter `project_id` (Bubble treats this as dynamic) - Add a query parameter `per_page`: `10` (limits to last 10 pipelines) - Set 'Use as': Data - Initialize — provide your actual numeric project ID when prompted. A successful response returns an array of pipeline objects with fields: `id`, `status` (created/pending/running/failed/success/canceled/skipped), `ref` (branch name), `created_at`, `updated_at`. Call 2 — Get Open Issues: - Add another call, name 'Get Issues' - Method: GET - URL: `https://gitlab.com/api/v4/projects/{project_id}/issues` - Parameters: `state=opened`, `per_page=25` - Set 'Use as': Data - Initialize with your project ID Call 3 — Get Merge Requests: - Name: 'Get Merge Requests' - Method: GET - URL: `https://gitlab.com/api/v4/projects/{project_id}/merge_requests` - Parameters: `state=opened`, `per_page=25` - Set 'Use as': Data - Initialize Call 4 — Trigger Pipeline (for the Deploy button): - Name: 'Trigger Pipeline' - Method: POST - URL: `https://gitlab.com/api/v4/projects/{project_id}/pipeline` - JSON body: `{"ref": "main"}` (or whichever branch to trigger) - Set 'Use as': Action - Note: triggering a pipeline via the projects API requires `api` scope on your token (not `read_api`)

1GET https://gitlab.com/api/v4/projects/{project_id}/pipelines
2Headers:
3  PRIVATE-TOKEN: <private>
4  Content-Type: application/json
5Query Params:
6  per_page: 10
7
8Example response item:
9{
10  "id": 1234,
11  "status": "success",
12  "ref": "main",
13  "sha": "a1b2c3d4",
14  "created_at": "2026-07-09T14:30:00.000Z",
15  "updated_at": "2026-07-09T14:45:00.000Z",
16  "web_url": "https://gitlab.com/org/repo/-/pipelines/1234"
17}

Design the Bubble page that displays your GitLab DevOps data. The most powerful UI feature for a pipeline dashboard is conditional color coding — pipeline status values map naturally to colors. Go to the Design tab. Create a new page or use an existing one. Add a Repeating Group for pipelines: - Type of content: 'GitLab Get Pipelines' - Data source: 'Get data from external API' → GitLab - Get Pipelines → project_id: your project ID - Layout: Full List with columns for status, branch, and time Inside the first Repeating Group cell: - A Text element for the pipeline ID (bind to current cell's id field) - A Text element for the branch name (bind to ref) - A Text element for the status (bind to status) - A Shape or Group element as a status indicator dot To add color coding on the status indicator Shape: - Click the Shape element → go to the 'Conditional' tab in the properties panel - Add condition 1: 'When: Current cell's GitLab Get Pipelines's status = success' → Change Style: Background color = green (#28a745) - Add condition 2: 'When: status = failed' → Background color = red (#dc3545) - Add condition 3: 'When: status = running' → Background color = blue (#007bff) - Add condition 4: 'When: status = pending OR status = created' → Background color = yellow (#ffc107) - Default (no condition matches): gray (#6c757d) Below the pipeline Repeating Group, add a second Repeating Group for open issues and a third for merge requests, following the same pattern with their respective API calls. For the 'Deploy to Staging' button: - Add a Button element, label it 'Trigger Deployment' - Create a Workflow: on button click → Plugins → GitLab - Trigger Pipeline → project_id: your project ID, ref: 'staging' - Add a second workflow action: Show element → a 'Deployment triggered!' text alert Rate limit awareness: GitLab's API has a rate limit of approximately 10 requests per second per IP (this applies to Bubble's server IP, shared across all your Bubble users). If your dashboard loads 3 API calls on page load and you have 50+ concurrent users, you may approach this limit. Mitigate by caching pipeline and issue data in a Bubble data type and refreshing it every 5 minutes via a scheduled API workflow (paid Bubble plan), rather than calling GitLab on every page load.

GitLab can send webhook events to an external URL when specific events occur — pushes, pipeline completions, issue updates, merge request events. You can use a Bubble Backend Workflow URL as the target, so Bubble automatically reacts to GitLab events (e.g., update a cached pipeline record when GitLab signals a pipeline completed). Prerequisite: Backend Workflows require a paid Bubble plan. The Free plan cannot expose webhook endpoints. If you're on the Free plan, implement a manual 'Refresh Data' button instead. For paid plan users: 1. In Bubble editor → Settings → API → enable 'This app exposes a Workflow API'. Save. 2. Go to Backend Workflows section. Click 'Add API Workflow'. Name it 'gitlab_pipeline_event'. 3. Click 'Detect request data'. Bubble shows the initialization URL: `https://yourappname.bubbleapps.io/api/1.1/wf/gitlab_pipeline_event/initialize` 4. In GitLab, go to your project → Settings → Webhooks → Add new webhook. 5. Paste the PRODUCTION URL (without /initialize): `https://yourappname.bubbleapps.io/api/1.1/wf/gitlab_pipeline_event` 6. In the 'Secret token' field, enter a random string you'll also store in a Bubble workflow condition for verification. 7. Check 'Pipeline events' and 'Issues events'. Click 'Add webhook'. 8. GitLab has a 'Test' button — click it to send a test payload. Bubble receives the payload and you can now map detected fields in the Backend Workflow. 9. Add workflow actions: create or modify a 'GitLabPipeline' data type record with the incoming status, project ID, and pipeline ID from the detected data. RapidDev's team has built real-time DevOps dashboards in Bubble with GitLab webhook integration — if you want expert help setting up the full pipeline notification system, book a free scoping call at rapidevelopers.com/contact.

1Production webhook endpoint URL:
2https://yourappname.bubbleapps.io/api/1.1/wf/gitlab_pipeline_event
3
4Example GitLab pipeline webhook payload:
5{
6  "object_kind": "pipeline",
7  "object_attributes": {
8    "id": 1234,
9    "ref": "main",
10    "status": "success",
11    "duration": 120,
12    "finished_at": "2026-07-09T14:45:00.000Z"
13  },
14  "project": {
15    "id": 567,
16    "name": "My App",
17    "web_url": "https://gitlab.com/org/my-app"
18  }
19}