# Built into Bumpkit

These work without another product's account.

## Outbound webhook

```bash
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 | When | Payload |
|-------|------|---------|
| `release.analyzed` | A release is recorded by `POST /v1/analyze` | `event`, `timestamp`, `version` (`previous`, `suggested`, `bump`), `signal` (0 to 1, how much usable change information the commits carried), `changelog.formatted`, `repository.url` |
| `webhook.test` | An owner or admin clicks **Send test** or runs `bumpkit integrations test webhook` | `event`, `timestamp`, `message` |
| `release.regressed` | Release health finds a regression | `event`, `timestamp`, `repository`, `environment`, `version`, `reason`, `suspect`, `url` |

```json
{
  "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](/docs/compliance#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](/docs/release-health#signed-webhook) 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:

```bash
bumpkit deploy --environment production
```

Or call `POST /v1/deployments` from anywhere; the `deploy` MCP tool does the same. Deploy webhooks from [Argo](/docs/argo), [Railway](/docs/railway) and [Vercel](/docs/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](/docs/release-health#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`.

```bash
bumpkit hooks install --git
```

An existing hook is never overwritten. See [Agent hooks](/docs/agent-hooks#git-pre-push).

## CI gate

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

```bash
bumpkit gate
```

[Run it in CI](/docs/release-gate#run-it-in-ci) has the setup for each one:

- [GitHub Actions](/docs/release-gate#run-it-in-github-actions)
- [GitLab CI](/docs/release-gate#run-it-in-gitlab-ci)
- [Bitbucket Pipelines](/docs/release-gate#run-it-in-bitbucket-pipelines)
- [Azure Pipelines](/docs/release-gate#run-it-in-azure-pipelines)
- [Buildkite](/docs/release-gate#run-it-in-buildkite)
- [CircleCI](/docs/release-gate#run-it-in-circleci)
- [Jenkins](/docs/release-gate#run-it-in-jenkins)

See also [`bumpkit gate`](/docs/cli-checks#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:

```yaml
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`](/docs/bumpkit-yml#require-checks).

## Local MCP server

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

```bash
bumpkit mcp
```

See [The local MCP server](/docs/mcp#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.

```sh
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.