Jenkins webhooks

Q: What happens if Jenkins sends the same event twice?

Redeliveries are deduplicated on The id or event_id field in the body, when present, namespaced per source, so a repeat becomes the same event rather than a second one.

Build and pipeline notifications, authenticated by a header token.

In short

Verification: a constant-time header token.
Deduplication: The id or event_id field in the body, when present.
Once verified, the event joins your catalogue with the same retries, log and replay as anything you publish yourself.

The contract

Field	Value
Provider key	`jenkins`
Header checked	`x-hookget-token` (also accepted: `Authorization: Bearer`)
Scheme	A constant-time comparison of a header token. This provider does not sign its payloads with a scheme we can standardise on, so the token is what authenticates the sender. It is never accepted from the query string.
Deduplicated on	The `id` or `event_id` field in the body, when present
Event type	The `type` or `event` field in the body becomes `jenkins.<type>`.

Setting it up

# 1. create a verified source; the secret is shown once
curl -X POST https://api.hookget.com/v1/sources \
  -H "authorization: Bearer $HOOKGET_KEY" \
  -H "content-type: application/json" \
  -d '{"provider":"jenkins","name":"Production"}'

# {"id":"src_…","secret":"whsec_…","ingest_path":"/ingest/src_…"}

Create the source and copy the ingest URL and secret.
In the sending system, add the ingest URL as the webhook destination.
Add a request header x-hookget-token whose value is the source secret.
Send a test event and watch it land in the event log.

Worth knowing. A token in a header is only as private as the transport. The ingest URL is served over TLS and the token is never logged; do not paste it into a query string, which would be.

What you get after verification

The event appears in your log with a namespaced type, so Jenkins traffic never collides with your own.
It fans out to your destinations with the same retry schedule and dead-letter behaviour as any other event.
The source secret rotates with an overlap window, so you can update Jenkins at your own pace.
Each inbound source is rate limited on its own, so a busy provider cannot exhaust your publish budget.

Questions

How do I verify a Jenkins webhook?

A constant-time comparison of a header token. This provider does not sign its payloads with a scheme we can standardise on, so the token is what authenticates the sender. It is never accepted from the query string. With HookGet you do not implement it: the source is created with a secret, and every request is checked against x-hookget-token (also accepted: Authorization: Bearer) before the event exists.

What happens if Jenkins sends the same event twice?

Redeliveries are deduplicated on The id or event_id field in the body, when present, namespaced per source, so a repeat becomes the same event rather than a second one.

What if verification fails?

The request is refused with 401 and nothing enters the pipeline. The rejection is logged on our side as a signal worth watching; the caller learns nothing beyond the status.