GitHub Webhook Tester: Inspect Payloads and Deliveries

A GitHub webhook test should answer four questions: did GitHub reach the payload URL, which event was sent, what JSON arrived, and what response did the endpoint return. A temporary request inspector is useful because it removes your application code from that first delivery check.

The test does not prove that your production parser, signature validation, queue, or business logic is correct. It gives you a known delivery sample and the HTTP evidence needed to build those parts accurately.

Use repository or organization test data. Webhook payloads can contain repository names, user details, issue text, commit metadata, and other information that should not be copied into a public debugging tool without review.

Create a temporary endpoint here, then add a webhook in the relevant GitHub repository, organization, or GitHub App settings. Paste the temporary URL into the payload URL field and choose application/json when you want a directly readable JSON body.

Subscribe only to the event needed for the integration. A focused push, issues, pull_request, or ping test is easier to reason about than sending every event type to the same debugging session.

Save the webhook and trigger the real action, or use GitHub delivery controls when available. Keep the GitHub delivery page and the request inspector open together so the sender record and receiver record can be compared.

Start with X-GitHub-Event. Your production router should use this header to choose the correct event contract instead of guessing from fields in the body. Use X-GitHub-Delivery as the stable identifier in logs and duplicate-detection records.

When a secret is configured, X-Hub-Signature-256 contains the SHA-256 signature. Capture the raw body exactly as received because parsing and re-serializing JSON before verification can change bytes and cause a valid signature check to fail.

Compare the payload with the official event documentation and keep fixtures for the event variants your code supports. A pull request event with action opened is not interchangeable with synchronize, closed, or reopened.

A missing request usually points to the payload URL, DNS, TLS, firewall, or routing. A received request with a non-success response points to receiver validation or application behavior. A timeout means the receiver should acknowledge sooner and move work to a background queue.

Use GitHub delivery history to inspect the recorded request and response. After fixing the endpoint, redeliver the same delivery instead of creating an unrelated event. That gives you a cleaner before-and-after comparison.

Treat repeated deliveries as normal. Store the delivery ID, make processing idempotent, and return a safe success response when an already-processed delivery arrives again.

Replace the temporary URL with your controlled HTTPS endpoint. Verify X-Hub-Signature-256 before trusting the payload, use constant-time comparison, and reject requests that do not match the configured secret.

Acknowledge valid deliveries quickly and queue slower processing. Log the delivery ID, event name, response status, and processing outcome without logging secrets or unnecessary personal data.

Turn captured test payloads into fixtures, then cover signature failures, duplicated delivery IDs, unsupported actions, malformed JSON, and temporary downstream failures in automated tests.