Buildkite

Overview
How to connect
Automated checks
Useful links

Connect Buildkite with a personal API access token to sync organization members and pipelines, and run access reviews. Read-only.

Read-only access. DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.

DSALTA collects this integration’s data when you connect it — you can refresh it at any time with Sync from integrations on the Integrations page. The compliance checks below re-run once a day at 02:00 America/New_York.

What DSALTA reads

DSALTA reads the Buildkite organization member roster — name, email and role (Admin or Member) — which appears on your Access page (Buildkite’s members API returns no account status, so every row is recorded as Active); and your Buildkite resources, which appear on your Inventory page.It calls these Buildkite endpoints:

/access-token
/organizations/{orgSlug}/members
/organizations/{orgSlug}/pipelines

Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Buildkite environment.

Troubleshooting

The connection fails to validate

Invalid token, wrong organization slug, the token is missing the read_organizations scope, or the token was created while viewing a different Buildkite organization than this slug.

How do I check whether the connection is healthy?

Open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Manage on the integration’s card. Open the Status tab: it shows either Connected and working properly or Connection issues detected.Use the Status tab, not Overview — Overview always reports Connected regardless of the real state.

A check shows Failed and nothing changed on my side

On an integration-powered check, Failed normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to Source Data, and read the result code: 403 is a missing permission, 428 is a setting DSALTA still needs, 500 is a failure on DSALTA’s side.A real compliance gap shows 207 and leaves the test looking Completed. See Understanding Test Results.

Data looks out of date

Compliance checks re-run once a day at 02:00 America/New_York. To refresh sooner, open Integrations → Connected and click Sync from integrations at the top right — it refreshes every connected integration at once.

How do I repair a broken connection?

There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

Disconnecting is destructive and cannot be undone. DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see Integration errors.

Configure scope will not let me change anything

That is expected. Configure scope is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.

A Buildkite personal API access token with the read_organizations scope. Read-only.Before you begin

A Buildkite account (free plan works)
If you belong to more than one Buildkite organization, switch to the correct one BEFORE creating the token — a token created under the wrong organization will fail to connect, even though it looks valid
A personal API access token with the read_organizations scope (add read_pipelines too, to sync pipelines)

You will need:

Field	Where to find it	Example
API Access Token	Open	`Buildkite personal API access token`
Organization Slug	See the steps below	`your-org-slug`

Start in DSALTA

Open Integrations in the DSALTA sidebar, find Buildkite, and click Connect to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.

Create an API access token

If you belong to more than one Buildkite organization, switch to the one you want to connect FIRST (top-left organization switcher) — a token created while viewing the wrong organization won’t be able to see it, and will fail to connect. Then go to buildkite.com/user/api-access-tokens and click New API Access Token. Give it a description (e.g. DSALTA), and under REST API enable read_organizations (and read_pipelines if you want DSALTA to also sync pipelines). Click Create Token.In the New API Access Token form, confirm the organization you want to connect is ticked under Organization Access — Buildkite’s own instruction is to “ensure the appropriate Buildkite organization is selected in Organization Access”, and that setting is what makes an otherwise valid token invisible to the org you meant. Leave Credential Type on Token (the default): DSALTA authenticates with a bearer token.

Set Token Expiry deliberately. Buildkite’s docs say a Token credential’s expiry “defaults to seven days if left unset”, so a token created without thinking about it can stop your daily sync a week after you connect — and there is no Reconnect button, so recovering means disconnecting (which deletes the evidence collected from Buildkite) and connecting again with a new token.

Buildkite's API Access Tokens page with the New API Access Token button and an existing token showing no expiry, 7 read permissions and 1 org

Copy the token and find your organization slug

Copy the access token — it’s shown only once. Your organization slug is the part of your Buildkite URL right after buildkite.com/, e.g. buildkite.com/acme-inc has the slug acme-inc.

Connect Buildkite

Paste your API access token and organization slug, then click Connect.

DSALTA validates the credential when you click Connect. On success the integration moves to the Connected tab, and Manage → Status reads Connected and working properly. Checks begin reporting after the first sync.

If the connection is rejected. Invalid token, wrong organization slug, the token is missing the read_organizations scope, or the token was created while viewing a different Buildkite organization than this slug.The on-screen message is generic — see Connection error messages.

Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.

Check	Severity	What it verifies
User access to Critical System should be valid	Info	Checks that everyone with Buildkite access is an active employee on the People page.
Offboarded users should not have active access	High	Checks that offboarded employees no longer have active Buildkite access.

Topic	Link
Setup	Create a Buildkite API access token
General	Buildkite website
DSALTA	Connection error messages

Getting Connected

Identity Providers

Cloud Infrastructure

Code Repositories

Security & Monitoring

Databases

SaaS & Productivity

What DSALTA reads

Troubleshooting

​What DSALTA reads

​Troubleshooting

What DSALTA reads

Troubleshooting