A webhook tester helps you send or receive a sample webhook, inspect its HTTP request and response, and determine why delivery succeeded or failed. The useful result is not merely a green status: it is evidence that the sender attempted the right event, the receiver accepted the authentic request, and the intended downstream action happened exactly once.
Production webhook testing should connect sender evidence to receiver evidence, not stop at a disposable URL. Runner AI publishes this guide and provides a webhook workbench in eligible workspaces, but the method applies to any provider and receiver. In Runner, open Build → Webhooks only when that entry is exposed; an embedded provider portal may present different controls.
Key Takeaways
- Test the sender, HTTP exchange, and business effect as separate checkpoints.
- A
2xxresponse proves HTTP acceptance, not successful processing.- Verify signatures against the exact raw request body when the provider requires it.
- Make receivers idempotent and duplicate-safe before resending or replaying events.
- Replay only a bounded, understood set of events and confirm the receiver’s final state.
What does a webhook tester actually test?
A webhook tester can describe several different tools. A public catcher typically gives you a hosted URL and displays requests sent to it. A local tunnel exposes a development server. A sender dashboard may generate test events and show delivery attempts. An automated test harness can call the receiver directly and assert its final state.
Each answers a different question:
| Test surface | Question it answers | What it cannot prove alone |
|---|---|---|
| Public catcher | Did a request reach this temporary URL, and what did it contain? | That your production receiver accepts or processes it |
| Local receiver or tunnel | Does the current receiver code handle this request? | That the real sender is configured correctly |
| Sender delivery log | Did the provider attempt delivery, and what response did it record? | That the receiver committed the intended business action |
| Receiver record | Did the receiver authenticate, process, and persist the event? | That every sender retry or event type behaves correctly |
This distinction matters because webhooks cross an ownership boundary. The sender chooses when and how to deliver. The receiver controls its endpoint, authentication, parsing, deduplication, processing, and response. Standard Webhooks describes webhooks as HTTP callbacks and documents common security and reliability conventions, but every provider’s contract still governs its actual behavior.
How can you test a webhook end to end?
Use one harmless event and build a trace that both sides can recognize. Record the event type, sender event or delivery ID, destination, attempt time, response status, receiver correlation ID, and resulting business record. Do not begin with a bulk replay or a real customer transaction.
1. Define the expected event and business effect
Write one sentence before sending anything: “When event X arrives for test object Y, receiver Z should create or update record Q once.” This gives you a result to verify rather than a payload to admire.
Subscribe only to the event types the integration needs. GitHub explicitly recommends selecting the minimum required events, using HTTPS, setting a webhook secret, and checking its unique delivery identifier in its webhook best practices. Those are sound defaults, although exact fields and delivery rules remain provider-specific.
2. Send a harmless test event
Prefer a provider-generated example, sandbox event, or object created only for testing. Keep real personal, credential, and payment data out of public webhook catchers. A temporary receiver is useful for inspecting payload shape, headers, and event selection, but it should not become an informal production log.
If you use Runner’s first-party workbench, Catalog can show an event’s schema and example before you send it. A test send lets you exercise a configured endpoint. Use the Runner webhook guide for the current entry path and the distinction between the first-party workbench and an embedded provider portal.
3. Match the sender attempt to the receiver record
On the sender side, capture whether an attempt exists, when it started, the final HTTP status, and any timeout or connection error. On the receiver side, locate the same event by a provider event ID, delivery ID, or another stable correlation value. Compare the payload identity and timestamp before assuming two nearby records belong together.
In Runner, Endpoints, Catalog, Logs, and Activity provide separate views of configuration, available event types, recorded deliveries, and recent activity when the workbench is enabled. Delivery logs can show message-scoped attempt history, with request and response body tabs for an available attempt. Compare that delivery status with the receiver’s own record; an endpoint saved in the dashboard is configuration evidence, not delivery evidence.
4. Verify authenticity before processing
The receiver should verify the provider’s signature according to that provider’s documentation before trusting or acting on the body. Keep the signing secret out of logs, screenshots, catchers, source control, and support messages. If it leaks, replace it in both the sender and receiver before sending more events. Use a managed secret store and follow the same handling principles used for API keys and other credentials.
Body handling can be exacting. Stripe, for example, requires the unmodified raw request body for signature verification; parsing or changing it first can make verification fail. Stripe also recommends returning a successful 2xx quickly before complex logic and documents duplicate events, automatic retries, and the lack of guaranteed event ordering in its webhook documentation. Apply those statements to Stripe, then check your own sender’s documentation rather than treating them as universal timing or retry rules.
5. Confirm the business effect
After the receiver accepts the request, verify the specific outcome: the test order changed state, the test deployment was queued, or the intended audit record exists. Check that the effect happened once, that unrelated records did not change, and that a duplicate delivery would not repeat a charge, email, shipment, or destructive update.
This last checkpoint separates transport success from application success. It also protects broader automations: a webhook may start an order, return, or operational workflow, where one duplicate can fan out into several side effects.
How do you diagnose webhook failures?
Start with the earliest missing evidence. If the sender has no attempt, inspecting receiver code is premature. If the sender has an attempt but no HTTP response, work on connectivity before business logic. If HTTP succeeded but the business state did not change, follow the receiver after acknowledgement.
HTTP status codes are grouped by class in RFC 9110, Section 15, but a sender dashboard decides how it labels, retries, and surfaces each outcome. Use this matrix to choose the next investigation, then consult the sender’s documentation for its exact behavior.
| Evidence | Likely boundary | What to inspect next | Safe next test |
|---|---|---|---|
| No sender attempt | Event selection or sender configuration | Subscription, environment, endpoint status, event eligibility | Generate one known eligible test event |
| Connection or TLS failure | DNS, certificate, firewall, proxy, or unavailable receiver | Sender error, DNS resolution, certificate chain, ingress logs | Probe the HTTPS endpoint without a real payload |
3xx response |
Redirect at the receiver edge | Redirect target, method preservation, sender redirect policy | Configure the final HTTPS URL directly |
4xx response |
Request rejected | Authentication, signature, route, headers, body parser, schema | Reproduce with the saved test request after removing secrets |
5xx response |
Receiver failed while handling request | Application exception, dependency failure, transaction logs | Fix the receiver, then resend only the test event |
| Timeout | Receiver too slow or response lost | Work before acknowledgement, queue handoff, network timing | Acknowledge after durable intake; process slow work separately |
2xx but no business effect |
Failure after acceptance or wrong expectation | Queue, worker, deduplication, validation, transaction, final record | Trace the same event ID through receiver stages |
Do not collapse every 4xx, 5xx, or timeout into one “failed webhook” bucket. The status, response body, attempt sequence, and receiver log together tell you which team owns the next action. GitHub asks receivers to return a 2xx response within ten seconds, but that ten-second rule is specifically GitHub’s contract, not a general webhook standard.
How should resend and replay be used safely?
Resend usually means another attempt for one message. Replay often means sending a group of historical events again. Dashboard terms differ, so read the confirmation and provider documentation before acting.
Before either action, make the receiver idempotent. Store a stable provider event ID or delivery key with the committed effect, reject or safely ignore a duplicate, and make the check atomic with the business write where possible. A “seen” flag written before a failed transaction can lose work; one written after a side effect can allow the side effect twice.
Use this checklist:
- Choose a harmless test event and state the expected business effect.
- Remove real personal, payment, credential, and confidential data from any public catcher.
- Confirm the receiver verifies signatures using the sender’s current documentation, including raw-body requirements.
- Subscribe to the minimum event set needed for the integration.
- Confirm duplicate delivery is safe before resending.
- Fix the identified failure before creating another attempt.
- For replay, select a valid start time, add an end time when the replay should not continue through the present, and estimate which events and side effects it includes.
- Read the confirmation, execute once, and compare sender attempts with receiver records and final state.
In Runner’s workbench, resend uses a confirmation flow, and the confirmation remains open if the resend fails so the error is not mistaken for success. Replay requires a start time, validates any supplied end time, and asks for confirmation. These safeguards reduce accidental sends; they do not make a non-idempotent receiver safe.
If the Webhooks entry or a specific control is absent, do not infer a hidden URL or assume the feature is broken. Check Runner feature availability. Provider-managed embedded portals can also differ by account or release.
What should you record after a webhook test?
Keep a compact evidence record that another person can evaluate without rerunning the event:
- Event type and test object identifier
- Sender event or delivery ID
- Destination environment, without exposing secrets
- Attempt time, outcome, HTTP status, and sanitized response
- Signature verification result
- Receiver correlation ID and processing result
- Expected and observed business state
- Whether duplicate and out-of-order handling were tested
- Any resend or replay scope and approval
This record is also useful when evaluating a secure ecommerce website. Webhook endpoints, signing secrets, third-party access, logs, and recovery actions belong in the store’s broader security and incident evidence, not in an isolated developer checklist.
Put the evidence into a release decision
End the test with a handoff, not a generic “looks good.” Give the workflow owner one evidence packet containing the sender attempt, sanitized request and response, signature result, receiver record, final business state, and duplicate test. Ask them to approve activation only if every checkpoint matches; otherwise assign the failure to the earliest broken boundary and keep replay disabled.
Frequently asked questions
How can I test a webhook?
Create a harmless test event, send it to a controlled receiver, inspect the sender’s delivery attempt and HTTP exchange, verify the signature, then match the event to the receiver’s processing record and final business effect. A public catcher can confirm request shape and arrival, but it cannot prove your real receiver works.
What is a webhook tester used for?
A webhook tester is used to inspect payloads and headers, validate event subscriptions, reproduce authentication or parsing failures, observe response statuses, and confirm retry or duplicate handling. Production-minded testing also checks that the receiver performed the intended action once.
Are webhook testers free?
Free access, quotas, and retention vary by tool. Provider dashboards and advanced collaboration, security, or replay features may also depend on an account or paid plan. Review current terms and data handling before sending any payload.
Can I create my own webhook tester?
Yes. At minimum, create an HTTPS endpoint that preserves the raw body when required, captures safe request metadata, verifies the provider signature when the sender signs requests, returns an intentional response, and records a correlation ID. Add redaction, access control, retention limits, duplicate tests, and automated assertions before using it beyond local development.
If Runner’s Webhooks entry is available to your workspace, run one intentional test there, compare the delivery with the receiver’s record, and keep the resulting evidence packet with the integration’s release decision.