Is this a real GitHub webhook?

No. It is a single static commit served from your mock URL, without the X-Hub-Signature-256 header, sender, head_commit or compare URL that a real push event carries.

How do I test a push to a different branch?

Change ref in the response body — for example to refs/heads/release. Branch filtering is the most common piece of logic in a push handler and the easiest to get wrong.

Can I use it to test tag or delete events?

Only by editing the body to match those payloads, which differ in shape. For a handler that dispatches on event type, create one mock per event so each case has its own stable URL.

Mock a GitHub push webhook

A GET mock shaped like a GitHub push event, with one commit on refs/heads/main.

This template returns a GitHub-shaped push event with one commit on refs/heads/main, so you can develop a CI trigger or a bot handler without pushing to a real repository. It carries the fields most handlers actually branch on — ref, after, and the repository name — and omits the signature header, so it exercises your parsing rather than your verification.

Returns a ready-made event — feed it straight into your own handler.

Response payload

{
  "ref": "refs/heads/main",
  "before": "a10867b14bb761a232cd80139fbd4c0d33264240",
  "after": "b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9",
  "repository": {
    "full_name": "octocat/quickmock-demo"
  },
  "pusher": {
    "name": "octocat"
  },
  "commits": [
    {
      "id": "b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9",
      "message": "fix: handle empty payload",
      "timestamp": "2024-05-01T12:00:00Z"
    }
  ]
}

Fields worth knowing

Field	What it means
ref	The branch that was pushed to, e.g. refs/heads/main.
after	The commit SHA after the push — later GitHub API calls reference it.
repository.full_name	The repository name as owner/repo; edit it to match your test repo.
pusher.name	The GitHub username who pushed.
commits	The commits included in this push — trimmed to one here.

Create the mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"ref\":\"refs/heads/main\",\"before\":\"a10867b14bb761a232cd80139fbd4c0d33264240\",\"after\":\"b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9\",\"repository\":{\"full_name\":\"octocat/quickmock-demo\"},\"pusher\":{\"name\":\"octocat\"},\"commits\":[{\"id\":\"b7e1a2c3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9\",\"message\":\"fix: handle empty payload\",\"timestamp\":\"2024-05-01T12:00:00Z\"}]}"
}'

Call it

curl https://quickmock.dev/m/<slug>

What you get

GET /m/<slug> -> 200 a GitHub-style push event
one commit on refs/heads/main

How this differs from the real thing

This is a single static commit rather than the full field set a real push event carries — no X-Hub-Signature-256 header, no sender or head_commit, no compare URL.

Sources

FAQ

Is this a real GitHub webhook?: No. It is a single static commit served from your mock URL, without the X-Hub-Signature-256 header, sender, head_commit or compare URL that a real push event carries.
How do I test a push to a different branch?: Change ref in the response body — for example to refs/heads/release. Branch filtering is the most common piece of logic in a push handler and the easiest to get wrong.
Can I use it to test tag or delete events?: Only by editing the body to match those payloads, which differ in shape. For a handler that dispatches on event type, create one mock per event so each case has its own stable URL.

Ready to use it?

Open it in the mock builder to tweak first

Pairs well with this guide: Test a webhook receiver

Related templates

← All templates

Last updated: 2026-10-17