1. Overview
The Buildkite integration reads an authorized organization's delivery structure and build history through a workspace-managed API access token.
Seedling keeps pipeline, build, job, team, and artifact provenance attached to the exact connection and exposes no Buildkite mutation.
2. Connection and scope
Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.
- Buildkite API access token
- Use a token owned by an administrator or dedicated service account that can read the intended organization. An optional organization slug selects a specific visible organization.
- Connection ownership
- This connector is workspace-only. A current Seedling workspace administrator controls installation, credential replacement, disconnect, and purge for the exact connection.
3. Buildkite data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Delivery structure
- Organizations, pipelines, branches, steps, teams, agents, and environment metadata.
- Build execution
- Builds, jobs, states, commits, actors, timing, retries, and pipeline relationships.
- Artifacts
- Artifact identity, metadata, build/job provenance, and authorized supported content.
4. Read-only permission contract
Create a read-only Buildkite token with the exact released REST API scopes.
- read_user and read_organizations — verify the token identity and selected organization.
- read_pipelines and read_builds — read pipelines, builds, jobs, steps, and delivery state.
- read_artifacts — read artifact metadata and supported authorized content.
- read_teams — stage team context without treating membership as a complete object ACL.
- No pipeline, build, job, agent, team, or artifact write scope is requested.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough complete object-level audience evidence for Seedling to reproduce native permissions safely. Workspace content therefore uses the connection's restricted-by-default workspace-or-no-human-access policy; administrator and steward status grant no raw-content bypass.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized Buildkite records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored Buildkite credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.