Built into Bumpkit ​

These work without another product's account.

Outbound webhook ​

bumpkit integrations connect webhook --url https://hooks.acme.dev/bumpkit

The URL must be https on a public host. Bumpkit POSTs JSON with User-Agent: Bumpkit-Webhook/1.0 and an X-Bumpkit-Event header:

{
  "event": "release.analyzed",
  "timestamp": "2026-10-21T09:30:00.000Z",
  "version": { "previous": "1.4.2", "suggested": "1.5.0", "bump": "minor" },
  "signal": 0.92,
  "changelog": { "formatted": "## v1.5.0\n\n### Features\n..." },
  "repository": { "url": "https://github.com/acme/api" }
}

To stream the full audit trail to a SIEM instead, see Audit streaming.

Alert webhook ​

Send alerts from any monitoring tool to a signed webhook. Each alert is ranked against recent releases, with evidence. Add one on the Integrations page or with bumpkit sources add webhook --repository owner/name; see Release Health for the signature.

Deploy events ​

Tell Bumpkit what reached production and when, so release health, incidents and change tickets follow what actually shipped. Repositories with the Bumpkit GitHub App record GitHub deployments automatically. Otherwise, add one line after your deploy step:

bumpkit deploy --environment production

Or call POST /v1/deployments from anywhere; the deploy MCP tool does the same. Deploy webhooks from Argo, Railway and Vercel record deployments too, and their hooks endpoints allow 600 deliveries a minute per IP address. Deploys of a commit that was already deployed to that environment count as a rollback for change tickets. See Record deploys.

Git pre-push hook ​

Checks changes before a person or a coding tool pushes them. It works with anything that runs git push.

bumpkit hooks install --git

An existing hook is never overwritten. See Agent hooks.

CI gate ​

Run the release gate in any CI system with one command, and fail the job unless the release can ship:

bumpkit gate

Run it in CI has the setup for each one:

• GitHub Actions
• GitLab CI
• Bitbucket Pipelines
• Azure Pipelines
• Buildkite
• CircleCI
• Jenkins

See also bumpkit gate.

CI and code scanning ​

Gate on your tests passing and on open code scanning alerts. Name the checks that must pass, and the alert severity that blocks, in bumpkit.yml on your default branch:

gate:
  require_checks: [test, build]
  security_alerts: high

Bumpkit waits for required checks before deciding. If code scanning is unavailable, a security_alerts rule blocks the change rather than treating missing results as a pass. See require_checks.

Local MCP server ​

Run Bumpkit's MCP server on your machine for tools that read your checkout:

bumpkit mcp

See The local MCP server.

Configure incident and deploy sources in the CLI ​

Use bumpkit whoami to confirm the active workspace. The same workspace roles and beta availability as the dashboard apply. Owners and admins can add, set signing secrets and remove sources; listing never returns a signing secret.

bumpkit sources list sentry
bumpkit sources add sentry --repository owner/repo
bumpkit sources set-secret sentry SOURCE_ID --secret-env SENTRY_CLIENT_SECRET
bumpkit sources remove sentry SOURCE_ID --yes

Supported providers are sentry, pagerduty, datadog, webhook (the generic alert webhook), vercel, argocd and railway. Use the repository name exactly as recorded by your release checks; the CLI does not infer it from the current directory.

Sentry, PagerDuty and Vercel start as pending_secret. Obtain the provider's client or webhook signing secret, then use exactly one of --secret-stdin, --secret-env VARIABLE_NAME or --secret-file PATH. Pass the environment variable's name, not its value. Signing secrets are not accepted as literal command arguments and are not printed by set-secret.

Datadog, the generic alert webhook, Argo CD and Railway instead show a Bumpkit-generated signing secret once when added. Sign each alert webhook delivery with X-Bumpkit-Signature: sha256= and the HMAC-SHA256 of the body. Store it securely and send it in the displayed custom header. Their generated secrets cannot be changed with set-secret; remove and add a source deliberately to create a new one. PagerDuty and Vercel provider-issued secrets are never replaced with a generated substitute.

configured means the webhook details were saved. It does not prove that the provider delivered an event. Configure the displayed URL, signing header and payload in the provider, then check the resulting incident or deployment record. No provider account is changed automatically. --json returns the same metadata; adding a generated-secret source intentionally includes its one-time secret.

The matching API endpoints are GET /v1/sources/{provider}, POST /v1/sources/{provider}, PUT /v1/sources/{provider}/{id}/secret, and DELETE /v1/sources/{provider}/{id}. All use the authenticated key's workspace.