A real safe webhook capture
How to Test Webhooks and Inspect HTTP Requests Without Exposing Production Data
A practical workflow for debugging webhook delivery: verify the endpoint contract with controlled samples, inspect request details, and understand exactly what a temporary request bin does and does not protect.
Open toolBegin with a minimal event and a written expectation
Before sending anything, write down the method, endpoint path, required query parameters, content type, headers, body shape, signature behavior, and response your sender expects. Start with a small synthetic event such as a test ID and a harmless status value. This makes it possible to see whether the integration is wrong because of delivery, URL construction, serialization, headers, signing, or your receiver logic.
A request bin can show what arrived; it does not prove that a real provider will retry, sign, order, or authorize events exactly as your production environment does. Use it first to establish a visible baseline, then test the receiving application and the provider’s documented behavior in an authorized test environment.
Inspect the request in a useful order
Create one temporary endpoint, send the smallest test event, then compare the received method, path, query parameters, content type, headers, body size, and body against your written expectation. The tool can format JSON display when the content type indicates JSON, show non-text bodies as Base64, and produce a cURL representation for replaying a safe sample.
Check one difference at a time. An unexpected path often indicates base URL or routing configuration; missing query values can indicate encoding or proxy behavior; a different content type can change how a server parses the body; and an absent signature may mean the sender uses a test mode or a different event path. Do not “fix” these by copying production secrets into the test request.
Keep secrets out even when some headers are redacted
The temporary service automatically redacts `Authorization`, `Cookie`, `Set-Cookie`, `Proxy-Authorization`, `X-API-Key`, and header names containing `token` or `secret`. That protection is deliberately narrow: request bodies, query values, paths, ordinary header values, and generated cURL may still contain sensitive information. Never rely on automatic redaction as a data-classification system.
Use test credentials, redacted identifiers, placeholder email addresses, and harmless callback URLs. Do not send production API keys, bearer tokens, customer records, payment data, private file links, reset links, or live webhook events. If a real secret reached a temporary capture service, treat it as exposure: revoke or rotate it using the owning system’s procedure.
Know the endpoint lifecycle and access boundary
Each temporary endpoint lasts 30 minutes, retains up to 50 received requests, and accepts bodies up to 256 KB. The browser stores the management key in its current session and uses it to inspect, stream, and destroy the captured requests. The visible endpoint URL is an ingest address: anyone who knows it can send a request to it, so do not publish it or assume incoming traffic is trustworthy.
Destroy the endpoint when your test is complete instead of waiting for expiration. Create a fresh endpoint for a new test sequence, especially after sharing an endpoint URL in a ticket or chat. The service masks the displayed source IP, but do not use source address as an authentication decision; authenticate and verify signatures in the receiving application.
Move from observation to a repeatable integration test
Once the temporary capture matches your expected HTTP request, turn that harmless sample into an automated test in the receiver’s real runtime. Verify signature validation with test keys, idempotency behavior for duplicate events, timestamp or replay handling, schema validation, response status, retry logic, and observability. Keep the sample data and expected result with the integration rather than a screenshot alone.
This Webhook Tester is a temporary server-side service, unlike browser-local text tools. Requests are stored for the endpoint lifetime or until you destroy it. Treat its limits and redaction as debugging conveniences, not as a production data boundary, and follow your organization’s rules for third-party services, retention, access, and incident response.
Frequently asked questions
Are webhook bodies automatically redacted?
No. Certain sensitive headers are redacted, but request bodies, query parameters, paths, and many ordinary header values are retained and displayed.
Can anyone send requests to the temporary endpoint?
Yes. The endpoint is intended to receive requests, so anyone who knows its URL can send to it. Do not treat incoming requests as trusted or publish the endpoint.
Does seeing a request here prove my production webhook works?
No. It confirms the captured HTTP request. You still need to verify the provider contract, signature validation, receiver behavior, retries, and authorization in your own test environment.