Copy the endpoint
Every browser session gets a temporary random URL. No account, project or API key required.
Free • instant • no signup
Your webhook.
Under the microscope.
Generate a private temporary endpoint, send any HTTP request, and inspect every header, parameter and payload the moment it arrives.
24h auto-delete0 accountsLive SSE updatesGET→DELETE supported
Advertisement
Ad slot • responsive leaderboard
Live request inspector
Point. Ping. Inspect.
Your temporary endpointListening for requests…
Max payload 1.0 MBUp to 100 recent requestsDo not send production secrets
Quick startFire your first request
Inspector
Waiting for a request
Live
{
"sonar": "listening",
"next": "send a request"
}Zero configuration
Debug a webhook in three moves.
SONAR removes the setup work between “something is wrong” and seeing the exact request.
Send anything
Point Stripe test mode, GitHub, Zapier, your API client or a local script at SONAR.
Inspect the truth
See method, source, headers, parameters, JSON and raw body exactly as the server received them.
Webhook debugging guide
Understand webhooks without the fog.
Keep this page open beside your code. The tester above is for the live signal; this guide is for the “why is this behaving like that?” moments.
What is a webhook?
A webhook is an HTTP request one application sends to another when an event occurs. Instead of repeatedly asking an API whether something changed, the receiving application exposes a URL and waits. Payment providers can announce successful checkouts, source-control platforms can report pushes, and automation tools can forward data as soon as a workflow reaches a particular step.
The difficult part is usually not receiving a request. It is figuring out what was actually sent. A provider may report a successful delivery while your application behaves as if nothing arrived, or the payload shape may differ from the documentation. SONAR gives you a disposable endpoint so you can inspect the request independently from your production code.
How to test API payloads
1. Use a temporary endpoint
Copy the URL from the tester and paste it into your API client, webhook provider, automation tool or local development script. The endpoint is random and designed for short development sessions.
2. Send a realistic request
Use the same HTTP method and content type as the real integration. For JSON, send Content-Type: application/json. SONAR also captures GET parameters, plain text, PATCH requests and DELETE callbacks. If a JSON body is malformed, the raw body remains available for debugging.
3. Inspect every layer
Webhook failures often live outside the JSON body. Signatures and authorization metadata usually arrive in headers, while event IDs and tokens may be placed in the query string. Compare body, headers and query parameters before changing application logic.
Common webhook errors: HTTP 400 vs 500
A 400-level response generally means the receiver rejected something about the request. A 500-level response means the server accepted the connection but failed while processing the event.
StatusTypical meaningWhat to check
400Bad requestJSON syntax, required fields, content type
401 / 403Authentication failureKeys, signatures, timestamps
404Wrong routeEndpoint path and deployment URL
422Invalid business dataSchema rules and field values
500Server-side failureExceptions, logs and database calls
Safe webhook testing
Use test-mode credentials and synthetic data whenever possible. Avoid sending passwords, payment-card data, private health information or live production secrets to temporary debugging endpoints. For production systems, verify webhook signatures using the sender's official documentation and acknowledge valid events quickly.