GitLab Webhook Tester — Test & Inspect GitLab Webhooks Online

If you are wiring up GitLab webhooks, the first question is always the same: what does GitLab actually send? The docs show an idealised payload, but the real request — its headers, its X-Gitlab-Token header, the exact JSON shape — is what your handler has to parse. A GitLab webhook tester gives you a public URL that captures those real requests so you can read every byte before you write any code.

Get a free GitLab webhook tester URL

The fastest way is our free Webhook Bin — a no-code webhook tester that gives you an instant public URL and stores every request that hits it, headers and body included. No signup, no deploy:

1. Open the Webhook Bin and copy the URL it generates for you.
2. In Settings → Webhooks on a project or group, add a webhook endpoint and paste that URL.
3. Trigger an event (see below) and watch the request land in the bin in real time.

Because the bin keeps the full request, you can inspect the X-Gitlab-Token header, the Content-Type, and the complete payload — the three things you need to build and verify a handler.

What a GitLab webhook looks like

GitLab delivers webhooks as an HTTP POST with a application/json body. GitLab identifies the event with an X-Gitlab-Event header (e.g. Merge Request Hook) and authenticates with a flat X-Gitlab-Token you compare verbatim — capture both to confirm your setup before writing handler logic.

A typical Push Hook payload looks like this:

{
  "object_kind": "merge_request",
  "event_type": "merge_request",
  "object_attributes": {
    "iid": 1,
    "title": "Update README",
    "state": "opened",
    "action": "open"
  },
  "project": {
    "path_with_namespace": "group/project"
  }
}

Common GitLab events you will want to test:

• Push Hook
• Merge Request Hook
• Pipeline Hook
• Issue Hook

Verifying the GitLab signature

GitLab signs each request so you can prove it really came from GitLab. The signature travels in the X-Gitlab-Token header and is a plain secret-token comparison (no HMAC), using the secret token you configured. Capture a real request first, then use our HMAC signature verifier and the verify a webhook signature guide to confirm your verification logic against a payload you can actually see.

From inspecting to receiving on localhost

A bin is perfect for seeing the payload. When you are ready to drive your local handler with real GitLab events — without deploying — forward them straight to localhost with the Webhook Relay agent. The full walkthrough is here: Receive GitLab webhooks on localhost.

That gives you a stable public URL that tunnels to your machine, so GitLab keeps delivering to the same endpoint while you iterate on localhost, no firewall changes or public IP required.

Test GitLab webhooks online in three steps

1. Capture — point GitLab at a Webhook Bin URL and inspect the real request.
2. Verify — confirm the X-Gitlab-Token header with the HMAC verifier.
3. Forward — when the shape is clear, receive GitLab webhooks on localhost and build your handler.

New to webhooks in general? Start with what is a webhook and how to test webhooks.

Ready to inspect your first GitLab event? Open a free Webhook Bin and paste the URL into GitLab.