Travis CI

Log in to your Travis CI account at travis-ci.com. Click your profile avatar in the top-right corner and select 'Settings' from the dropdown. Scroll to the bottom of the Settings page to the 'API Authentication' section. Click 'Copy token' to copy your personal API token to the clipboard. This token is user-scoped — it grants access to all repositories and organizations visible to your Travis CI account. If you are building a Bubble integration for a specific organization, use the credentials of a service account or bot user scoped to that organization for production use. Save the token in a password manager. Note: this is the one credential you will place in Bubble's API Connector in the next step. Also note that travis-ci.org (the legacy domain) was permanently shut down in June 2021 — all API calls must go to api.travis-ci.com. If you have any old tutorials or examples referencing travis-ci.org, they no longer work.

1// Travis CI API Token location:
2// travis-ci.com → your profile avatar (top-right) → Settings
3// Scroll to: API Authentication → 'Copy token'
4
5// Important distinctions:
6// travis-ci.com  → ACTIVE (use this)
7// travis-ci.org  → DEPRECATED and shut down June 2021 (do not use)
8
9// Token scope: user-scoped (access to all repos/orgs your account can see)
10// For production: use a service account token
11
12// API base URL for all calls:
13// https://api.travis-ci.com

Open your Bubble app editor and click 'Plugins' in the left sidebar. If the API Connector plugin by Bubble is not already installed, click 'Add plugins,' search for 'API Connector,' and install it (it is free). Return to Plugins → API Connector. Click 'Add another API.' Name this group 'Travis CI.' In the 'Root URL' field, enter https://api.travis-ci.com (no trailing slash). Now add BOTH required shared headers — this is the most critical configuration step, and missing either header is the root cause of most Travis CI integration failures in Bubble. Click 'Add a shared header' twice to create two header rows. Header 1: key = 'Authorization', value = 'token YOUR_TOKEN_HERE' (replace YOUR_TOKEN_HERE with your actual token; the word 'token' is lowercase, followed by a single space, then the token string). Tick the 'Private' checkbox for this header — essential so the token stays on Bubble's servers. Header 2: key = 'Travis-API-Version', value = '3' (no Private checkbox needed — this is a public header). Do not use 'Bearer' as the prefix for the Authorization header. Travis CI's v3 API requires the exact format 'token YOUR_TOKEN' — using 'Bearer YOUR_TOKEN' returns a 403 or sometimes an empty response with no error message, making it very hard to debug.

1// Bubble API Connector — Travis CI group configuration
2{
3  "api_group_name": "Travis CI",
4  "root_url": "https://api.travis-ci.com",
5  "shared_headers": [
6    {
7      "key": "Authorization",
8      "value": "token YOUR_TOKEN_HERE",
9      "private": true,
10      "note": "CRITICAL: 'token' (lowercase) + space + your token. NOT 'Bearer'. NOT 'Token'."
11    },
12    {
13      "key": "Travis-API-Version",
14      "value": "3",
15      "private": false,
16      "note": "Required on all calls. Without this, Travis CI returns v2 response shapes."
17    }
18  ]
19}

Inside the Travis CI API group, click 'Add call.' Name this call 'Get Org Repos.' Set the method to GET. In the endpoint field, type /owner/{org}/repos (where {org} is a Bubble dynamic parameter). Set 'Use as' to 'Data.' Add URL parameters: 'limit' with example value '100,' and optionally 'include' with example value 'repo.last_build' — this tells Travis CI to embed the last build information in the repo list response, saving you a separate API call per repo. Add a 'sort_by' parameter with value 'last_build_at:desc' to get recently-active repos first. Now provide an example value for the {org} path parameter: enter your actual GitHub organization name or username. Click 'Initialize call.' Bubble fires a real GET request to api.travis-ci.com/owner/YOUR_ORG/repos with both shared headers. If successful, Travis CI returns a repositories list and Bubble detects the nested response fields: repositories (list), each with id, name, slug, description, last_build.state, last_build.number, last_build.branch, last_build.finished_at, and more. If initialization fails with 'There was an issue setting up your call': check that the Authorization header value starts with exactly 'token ' (lowercase t, space), the Travis-API-Version header is present, and your organization name is spelled correctly. Click 'Save.'

1// Bubble API Connector — Travis CI 'Get Org Repos' call
2{
3  "call_name": "Get Org Repos",
4  "method": "GET",
5  "endpoint": "/owner/{org}/repos",
6  "parameters": [
7    { "key": "limit",   "value": "100" },
8    { "key": "include", "value": "repo.last_build" },
9    { "key": "sort_by", "value": "last_build_at:desc" }
10  ],
11  "use_as": "Data"
12}
13
14// Travis CI v3 response shape:
15// {
16//   "@type": "repositories",
17//   "repositories": [
18//     {
19//       "id": 12345678,
20//       "name": "my-app",
21//       "slug": "my-org/my-app",
22//       "description": "Main application",
23//       "active": true,
24//       "last_build": {
25//         "id": 9876543,
26//         "number": "127",
27//         "state": "passed",
28//         "result": 0,
29//         "duration": 183,
30//         "branch": { "name": "main" },
31//         "finished_at": "2026-07-09T14:22:00Z"
32//       }
33//     }
34//   ]
35// }

Add a second call inside the Travis CI group. Name it 'Get Repo Builds.' Set the method to GET. The endpoint is /repo/{slug}/builds — but there is a critical path-encoding requirement: Travis CI repo slugs are in the format 'owner/repo-name' (for example, 'my-company/my-app'). The forward slash in the slug must be URL-encoded as '%2F' for Bubble's API Connector to correctly construct the URL path. In the endpoint field, enter /repo/{slug}/builds where {slug} is a dynamic parameter. When calling this from a Bubble workflow, the slug value must already be percent-encoded — for example, use 'my-company%2Fmy-app' rather than 'my-company/my-app.' Alternatively, use the numeric Travis CI repository ID (available from the Get Org Repos response as the 'id' field) in the endpoint /repo/{id}/builds — numeric IDs do not require encoding and are more reliable. Add URL parameters: 'limit' with value '25' and 'sort_by' with value 'id:desc'. Set 'Use as' to 'Data.' Click 'Initialize call,' providing a real repo slug (URL-encoded) or repo ID for the test. After initialization, Bubble detects build fields including number, state, branch, commit.message, duration, finished_at.

1// Bubble API Connector — Travis CI 'Get Repo Builds' call
2{
3  "call_name": "Get Repo Builds",
4  "method": "GET",
5  "endpoint": "/repo/{slug}/builds",
6  "parameters": [
7    { "key": "limit",   "value": "25" },
8    { "key": "sort_by", "value": "id:desc" }
9  ],
10  "use_as": "Data"
11}
12
13// IMPORTANT: URL encoding for repo slugs
14// Repo slug format: 'owner/repo-name'
15// When used in path: must encode '/' as '%2F'
16// Example:
17//   Unencoded slug: my-company/my-app
18//   URL for Bubble: /repo/my-company%2Fmy-app/builds
19//
20// Alternative: use numeric repo ID instead of slug
21//   Numeric ID from: repositories[0].id in Get Org Repos response
22//   No encoding needed: /repo/12345678/builds
23
24// Travis CI v3 build response:
25// {
26//   "builds": [
27//     {
28//       "id": 9876543,
29//       "number": "127",
30//       "state": "passed",
31//       "duration": 183,
32//       "branch": { "name": "main" },
33//       "commit": {
34//         "sha": "a1b2c3d4e5f6...",
35//         "message": "fix: resolve API timeout issue"
36//       },
37//       "finished_at": "2026-07-09T14:22:00Z"
38//     }
39//   ]
40// }

Navigate to the Backend Workflows section in Bubble's editor (available on Starter plan and above). Click 'Add a new API Workflow' and name it 'Sync Travis CI Status.' This workflow will run on a schedule to fetch and store Travis CI build data in Bubble's database. First, create a Bubble data type to hold the build data: click Data → Data types → Add a new type → name it 'BuildStatus.' Add fields: repo_name (text), repo_slug (text), repo_id (number), last_build_state (text), last_build_branch (text), last_build_number (text), last_build_duration (number), last_build_finished_at (date). Inside the 'Sync Travis CI Status' Backend Workflow, add these steps: Step 1 — Call the 'Get Org Repos' API Connector call with your organization name. Step 2 — Schedule API Workflow on a list using the result of Step 1 (the repositories list). The sub-workflow for each repository should: search for an existing BuildStatus record where repo_id = current repository's id; if found, update last_build_state, last_build_branch, last_build_finished_at; if not found, create a new BuildStatus record. Schedule the parent 'Sync Travis CI Status' workflow to recur every 600 seconds (10 minutes) by triggering it from an app startup workflow using 'Schedule API Workflow' with a recurs interval. This means Bubble polls Travis CI for your entire org's repo status every 10 minutes and serves the dashboard from its own database — no live API calls on user page loads.

1// Bubble data type: BuildStatus
2// Data → Data types → BuildStatus
3// Fields:
4// repo_name           — text
5// repo_slug           — text
6// repo_id             — number (use as deduplication key)
7// last_build_state    — text  (passed | failed | errored | canceled | started)
8// last_build_branch   — text
9// last_build_number   — text
10// last_build_duration — number (seconds)
11// last_build_at       — date
12
13// Backend Workflow: Sync Travis CI Status
14// Step 1: Call API > Travis CI > Get Org Repos (org = "your-org-name")
15// Step 2: Schedule API Workflow on a list
16//   List: Result of step 1 - repositories
17//   Workflow to run: Upsert BuildStatus
18
19// Sub-workflow: Upsert BuildStatus
20// Step A: Search for BuildStatus where repo_id = current_repo's id
21// Step B (if found):    Make changes to BuildStatus:
22//                        last_build_state = current_repo's last_build state
23//                        last_build_branch = current_repo's last_build branch name
24//                        last_build_at = current_repo's last_build finished_at
25// Step C (if not found): Create new BuildStatus:
26//                        repo_name = current_repo's name
27//                        repo_id   = current_repo's id
28//                        repo_slug = current_repo's slug
29//                        (+ all last_build fields)
30
31// Schedule recurring:
32// Action: Schedule API Workflow
33//   Workflow: Sync Travis CI Status
34//   Run at: Current date/time
35//   Recurs every: 600 seconds

**Dashboard page:** Create a Bubble page named 'ci-dashboard.' Add a Repeating Group with data type 'BuildStatus' and data source 'Do a search for BuildStatus, sorted by last_build_at descending.' Inside each cell, add: a colored Shape or Icon element (conditional green for 'passed,' red for 'failed,' orange for 'errored,' gray for 'canceled'), a Text element showing Current Cell's BuildStatus's repo_name, a Text element showing Current Cell's BuildStatus's last_build_branch, and a Text element showing Current Cell's BuildStatus's last_build_at formatted as relative time ('3 minutes ago'). Add a 'Last refreshed' text element at the top of the page bound to the most recent BuildStatus's last_build_at value. **Webhook path (optional, paid plan):** To receive real-time build notifications from Travis CI rather than polling, configure Travis CI to deliver webhooks to a Bubble Backend Workflow endpoint. In Bubble: Settings → API → enable 'This app exposes a Workflow API.' Create a Backend Workflow named 'travis-webhook.' Click 'Detect request data' and send a test webhook from Travis CI (in your .travis.yml file, add a notifications.webhooks.urls entry pointing to your Bubble workflow URL). After detection, map the payload fields (repository.name, build.state, build.branch, build.commit.message) to update or create a BuildStatus record. Your Bubble Backend Workflow URL format is: https://your-app.bubbleapps.io/api/1.1/wf/travis-webhook. Note that this endpoint is publicly reachable — Travis CI does not sign its webhook payloads, so add a secret URL path parameter (e.g., ?secret=RANDOM_STRING) to prevent unauthorized posts.

1// Bubble CI dashboard — Repeating Group conditional colors
2// Type: BuildStatus | Sort: last_build_at descending
3
4// Status badge element (Shape or Icon)
5// Default style: gray (unknown)
6// Conditionals:
7//   When Current Cell's BuildStatus's last_build_state = "passed"  → background #22c55e (green)
8//   When Current Cell's BuildStatus's last_build_state = "failed"  → background #ef4444 (red)
9//   When Current Cell's BuildStatus's last_build_state = "errored" → background #f97316 (orange)
10//   When Current Cell's BuildStatus's last_build_state = "started" → background #3b82f6 (blue)
11
12// Optional webhook endpoint URL:
13// https://your-app.bubbleapps.io/api/1.1/wf/travis-webhook
14
15// .travis.yml webhook configuration (for reference only — not Bubble code):
16// notifications:
17//   webhooks:
18//     urls:
19//       - https://your-app.bubbleapps.io/api/1.1/wf/travis-webhook?secret=YOUR_SECRET
20//     on_success: always
21//     on_failure: always
22
23// Travis CI webhook payload includes:
24// { "repository": { "name": "my-app", "owner_name": "my-org" },
25//   "branch": "main",
26//   "state": "passed",
27//   "build_url": "https://travis-ci.com/...",
28//   "message": "fix: resolve timeout issue" }