Test webhooks without guessing what arrived.

What a webhook tester actually solves

A webhook provider can report a successful delivery while your application still behaves as if nothing happened. The fastest way to separate a sender problem from a receiver problem is to point the webhook at an independent endpoint and inspect the request before your own application touches it.

SONAR acts as that neutral endpoint. It is useful when integrating payment gateways, source-control events, automation platforms, form tools, internal services and any system that can send an HTTP request to a public URL.

What SONAR captures

Each captured request includes the HTTP method, arrival time, source IP, content type, payload size, request headers, query parameters, parsed JSON when available and the original raw body. Malformed JSON remains visible as raw text so syntax mistakes do not disappear behind a parser error.

• GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS
• JSON and raw request bodies
• Headers such as signatures, authorization and content type
• Query-string values and repeated parameters
• Live request arrival without manually refreshing the page

How to test a webhook in three steps

Open the SONAR tester and copy your temporary endpoint. Paste that URL into the webhook configuration of the service you are testing. Trigger an event, then open the captured request in SONAR and compare the received payload with what your application expects.

curl -X POST "YOUR_SONAR_ENDPOINT" \
  -H "Content-Type: application/json" \
  -d '{"event":"order.created","id":"ord_123"}'

Use test data, not production secrets

Temporary request bins are debugging tools, not secret stores. Use sandbox credentials and synthetic payloads whenever possible. Avoid passwords, card data, private health information, access tokens or other production secrets. For real production endpoints, validate signatures and follow the sender's security guidance.