Getting Started with Webhooks

Create a webhook on one of your repositories from the Radicle Garden dashboard and verify it fires — no CLI or local key required. We’ll use webhook.site as a throwaway receiver so you can see a real delivery end to end. Takes about 5 minutes and is the recommended smoke test before you wire up a real CI system.

Prefer the command line? Everything below can also be done with the rad webhooks CLI → Manage Webhooks from the CLI.

Smoke test

Confirm the repo you want is seeded by your Garden node.
Open https://webhook.site. Copy the https://webhook.site/<uuid> URL shown at the top. Leave the tab open — it’s your throwaway receiver.
In the dashboard, find the repo and go to Settings → Webhooks for that repo, then click Add webhook.
Fill in the form:
- Payload URL — paste your webhook.site URL.
- Integration name — smoke-test.
- Secret — any string, e.g. any-string-is-fine-here.
- Leave Content type (application/json), SSL Verification (enabled), and Events (Just the push event) at their defaults, and keep Active checked.
Click Add webhook to save.

Trigger an event by pushing a commit to the repo’s main branch:

git commit --allow-empty -m 'Smoke-test webhook'
git push rad

Watch webhook.site — within ~30 s a POST should appear with a x-radicle-event-type: push header, an X-Hub-Signature-256: sha256=… signature (HMAC-SHA256 of the body using your secret), and a JSON body containing repository, after, branch, context, and commit_status_url.
Open the webhook in the dashboard and switch to the Recent deliveries tab — the same delivery is listed there with its request and response, so you can confirm it succeeded without leaving Garden.
Clean up: open the webhook’s overflow menu in the list and choose Delete (or just uncheck Active to pause it).

If nothing arrives, see Inspect recent deliveries below.

The webhook form, field by field

Field What it does

Field	What it does
Payload URL	The `http`/`https` endpoint we’ll send a `POST` request to when a subscribed event fires. Required.
Integration name	A unique identifier for this integration within the repo (for example `ci/build` or `jenkins`). This is the `context` that appears on commit statuses. It’s immutable once created — to rename, delete the webhook and create a new one.
Content type	The format of the request body: `application/json` (the default) or `application/x-www-form-urlencoded`.
Secret	Optional. If set, we sign each payload with HMAC-SHA256 so your receiver can verify the request really came from your Garden node. Configure the same secret in your CI system. When editing an existing webhook the secret stays masked — click Edit to rotate it. Leaving it blank on edit keeps the current secret unchanged.
SSL Verification	Leave enabled (recommended) so we verify the TLS certificate of your Payload URL. Disable it only for testing against an endpoint without a valid certificate.
Events	Which events deliver to this webhook (see below).
Active	When checked, we deliver events as they’re triggered. Uncheck to pause delivery without deleting the webhook.

Payload URL

The http/https endpoint we’ll send a POST request to when a subscribed event fires. Required.

Integration name

A unique identifier for this integration within the repo (for example ci/build or jenkins). This is the context that appears on commit statuses. It’s immutable once created — to rename, delete the webhook and create a new one.

Content type

The format of the request body: application/json (the default) or application/x-www-form-urlencoded.

Secret

Optional. If set, we sign each payload with HMAC-SHA256 so your receiver can verify the request really came from your Garden node. Configure the same secret in your CI system. When editing an existing webhook the secret stays masked — click Edit to rotate it. Leaving it blank on edit keeps the current secret unchanged.

SSL Verification

Leave enabled (recommended) so we verify the TLS certificate of your Payload URL. Disable it only for testing against an endpoint without a valid certificate.

Events

Which events deliver to this webhook (see below).

Active

When checked, we deliver events as they’re triggered. Uncheck to pause delivery without deleting the webhook.

Choosing events

Pick one of three modes:

Just the push event — fires only when the main branch is updated. A good default for most CI setups.
Send me everything — subscribes to every event type.
Let me select individual events — reveals checkboxes so you can subscribe to exactly the events you want. At least one is required.

The individual events are:

Event Fires when

Event	Fires when
`PATCH_CREATED`	A patch was created.
`PATCH_UPDATED`	A patch was updated.
`BRANCH_UPDATED`	A branch was updated (a push).
`BRANCH_DELETED`	A branch was deleted.
`TAG_CREATED`	An annotated tag was created.
`TAG_UPDATED`	An annotated tag was updated.
`TAG_DELETED`	An annotated tag was deleted.

PATCH_CREATED

A patch was created.

PATCH_UPDATED

A patch was updated.

BRANCH_UPDATED

A branch was updated (a push).

BRANCH_DELETED

A branch was deleted.

TAG_CREATED

An annotated tag was created.

TAG_UPDATED

An annotated tag was updated.

TAG_DELETED

An annotated tag was deleted.

Manage existing webhooks

From the repo’s webhooks list:

Edit — click a webhook row to open it. Change any field except the integration name.
Enable / Disable — use the row’s overflow menu to toggle delivery on or off (same as the Active checkbox).
Delete — use the overflow menu and confirm.

Inspect recent deliveries

When editing a webhook, switch to the Recent deliveries tab to see what was actually sent and what your endpoint returned — the fastest way to debug an integration:

the request headers and payload we sent,
the response status code (a 2xx shows as success, anything else as a failure), along with the response headers and body,
the delivery’s UUID (copyable) and timestamp.

If a delivery failed, the response body usually explains why. Common causes:

Nothing delivered at all — check the webhook is Active, that the event you expect is subscribed, and that the Payload URL is reachable from your Garden node (not just your laptop).
Signature mismatch on your receiver (401/403) — make sure the secret matches on both sides, and sign the raw request body. See the CLI troubleshooting notes for the exact signature format.

Once the smoke test works, you know the delivery path is healthy. Connect a real CI system → Jenkins setup guide.

Support