Testing an inbound webhook with sample events

Test an inbound webhook by sending a known event, checking the sender's delivery record, and comparing the receiver's decision and downstream result with what you expected. A 2xx response alone may confirm receipt while processing continues later.

Write the expected outcomes

Use a test source account or another safe environment, with an endpoint configured for that sender. Record the subscribed event, expected record identifier and intended destination effect. Keep test activity away from live customer records and communications.

For an illustrative order-change webhook, write the expected result before sending each sample:

This is a test plan, not a report of performed tests. The sender's response rules determine when an invalid delivery should receive an error and when it should be acknowledged for internal review.

Send a sender-generated event

Prefer a provider test facility or a disposable action that produces the subscribed event. GitHub documents triggering an event and inspecting its delivery.

For repository or organisation webhooks, its REST API can trigger a ping. A repository webhook subscribed to push can also receive a test push event through the documented API.

A ping checks that delivery reaches the endpoint, but it does not exercise an order-change handler. Follow it with a representative event for the workflow being tested.

A handcrafted request can help explore parsing, but label it as a local fixture. It does not establish that the real sender produced the same headers, signature or payload. GitHub's signature is derived from the configured secret and payload contents.

Use the chosen sender's verification method when checking an authenticated delivery.

Inspect delivery, decision and effect

Check the sender's record for the event type, sent request, time and response. GitHub's recent delivery view exposes request headers and payload, send time and the server response for deliveries from the past three days, subject to access permissions.

Avoid copying sensitive payloads into a separate test log when a safe identifier and result will suffice.

Then inspect the receiver's signature result, recognised event, identifier, routing decision and later processing result. Finally, inspect the destination record or state.

A sender delivery record establishes an attempted request and its response; it does not establish that the downstream action succeeded.

Where the provider supports redelivery, repeat a delivery and compare the result with the first attempt. GitHub allows authorised redelivery of deliveries from the past three days. Another sender may identify repeats differently.

Also check that a genuinely new event can still produce a new action.

For each sample, record the expected decision, observed receiver response, observed downstream result and any difference. Investigate a missing sender delivery separately from a receiver rejection or later processing failure. Re-run a failed case after a change and record the new observation.

Webhook Testing Metrics (GitHub)