How do I tell a merged pull request from one that was just closed?

Both arrive as action: "closed" — the difference is the boolean pull_request.merged. A merged PR has merged: true plus merged_at, merged_by, and merge_commit_sha; a discarded one has merged: false and null merge fields. Automation that branches on action alone will treat abandoned branches as deployments.

Which header identifies the event type?

X-GitHub-Event carries the event name, such as pull_request, while the action field inside the body carries the sub-type, such as opened or closed. X-GitHub-Delivery carries a unique id per delivery, which is what you should use for idempotency when GitHub retries.

Can I use this to test GitHub Actions workflows?

It is best for testing services that receive webhooks — bots, routers, and custom GitHub Apps. Actions workflows are triggered inside GitHub rather than by an inbound HTTP request, so for those the local runner approach is a better fit than a mocked payload.

~/tools / 08 / github-pull-request-event

GitHub Webhook Matrix

CI bots, merge queues, and deployment triggers all pivot on the pull_request event — specifically on action, merged, and the head/base refs. These templates replay the two payloads that matter most: a fresh "opened" PR your automation should pick up, and a "closed" event where merged: true separates a real merge from a discarded branch.

compose payload

template preset

status code latency (ms)

response body — live JSON editor

{
  "action": "opened",
  "number": 1347,
  "pull_request": {
    "id": 1901547821,
    "number": 1347,
    "state": "open",
    "title": "feat: add hash-based payload codec",
    "user": {
      "login": "octomocker",
      "id": 583231,
      "type": "User"
    },
    "body": "Implements deflate + base64url encoding for URL-fragment payloads.",
    "draft": false,
    "merged": false,
    "mergeable_state": "clean",
    "head": {
      "ref": "feat/hash-codec",
      "sha": "6dcb09b5b57875f334f61aebed695e2e4193db5e"
    },
    "base": {
      "ref": "main",
      "sha": "9049f1265b7d61be4a8904a9a27120d2064dab3b"
    },
    "html_url": "https://github.com/octomocker/mockdock/pull/1347",
    "additions": 214,
    "deletions": 12,
    "changed_files": 6,
    "created_at": "2026-07-05T13:01:22Z"
  },
  "repository": {
    "id": 35129377,
    "full_name": "octomocker/mockdock",
    "private": false,
    "default_branch": "main"
  },
  "sender": {
    "login": "octomocker",
    "id": 583231
  }
}

— validating —

exported mock url

—

▸ open mock ↗

simulated response headers

content-type: application/json

x-github-event: pull_request

x-github-delivery: 72d3162e-cc78-11e3-81ab-4c9367dc0958

x-hub-signature-256: sha256=mock_not_a_real_signature

$ man github-pr

Everything above is encoded into the #data= fragment of the exported URL — deflated and base64url-packed by your browser. Fragments are never sent to any server, so this mock is shareable and private. Paste the URL anywhere: a teammate's browser decodes it identically.

cat ./tldr.txt

A GitHub pull_request webhook mocker generates the opened and closed event payloads GitHub sends to CI bots and automation — including action, merged, head and base refs, repository, and the X-GitHub-Event headers — without needing a repository or webhook configuration.

./when-to-use-this

Your merge-queue bot must distinguish a genuinely merged PR from one closed without merging.
You are building a GitHub App and need to develop the event router before registering webhooks.
A deployment trigger fires on the wrong branch and you need to replay the payload with different base refs.

./frequently-asked

How do I tell a merged pull request from one that was just closed?: Both arrive as action: "closed" — the difference is the boolean pull_request.merged. A merged PR has merged: true plus merged_at, merged_by, and merge_commit_sha; a discarded one has merged: false and null merge fields. Automation that branches on action alone will treat abandoned branches as deployments.
Which header identifies the event type?: X-GitHub-Event carries the event name, such as pull_request, while the action field inside the body carries the sub-type, such as opened or closed. X-GitHub-Delivery carries a unique id per delivery, which is what you should use for idempotency when GitHub retries.
Can I use this to test GitHub Actions workflows?: It is best for testing services that receive webhooks — bots, routers, and custom GitHub Apps. Actions workflows are triggered inside GitHub rather than by an inbound HTTP request, so for those the local runner approach is a better fit than a mocked payload.

GitHub Webhook Matrix

cat ./tldr.txt

./when-to-use-this

./frequently-asked

grep -i related-searches

ln -s ./related-tools