Linking Bitrise as a source
This source is currently in alpha. The interface and available tables may change.
The Bitrise connector pulls your CI data into the PostHog data warehouse, including apps, builds, workflows, and build artifacts, so you can analyze build durations, failure rates, and release cadence alongside your product data.
Prerequisites
You need a Bitrise account with access to the apps you want to sync, and a personal access token or workspace API token.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
You need a Bitrise API token:
- Personal access token: create one in your Bitrise security settings. It has access to the same apps as your user.
- Workspace API token: create one from your workspace's settings page. It is scoped to a single workspace and is the more secure option for team use.
Paste the token in the API token field and click Next.
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
The builds table supports incremental sync on triggered_at. Note that the Bitrise API only returns builds from roughly the last 200 days, so older builds are not synced.
The artifacts table is disabled by default because it makes one API request per build. Enable it only if you need artifact metadata.
Configuration
| Option | Type | Required |
|---|---|---|
API token | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
apps | An app registered on Bitrise, tying a source code repository to its CI configuration. | Full refresh | — | — |
builds | The Bitrise API only returns builds from roughly the last 200 days | Incremental, Full refresh | triggered_at | — |
workflows | A workflow defined in an app's Bitrise configuration, one row per app and workflow name. | Full refresh | — | — |
artifacts | Fetches artifacts for every build, one request per build. Disabled by default because of the API cost | Incremental, Full refresh | build_triggered_at | — |
Troubleshooting
- Invalid Bitrise API token: the token is invalid or has been revoked. Create a new token in your Bitrise security settings and reconnect the source.
- Missing builds: the Bitrise API caps the builds listing at roughly the last 200 days. Builds older than that are not available to sync.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.