Use the Bin as a Diagnostic Boundary
A request bin is most useful as a temporary boundary between a sender and your application. Point the sender at a controlled public URL. If the event appears there, the provider can emit the event and reach the public internet; the remaining problem is probably in the original destination, its proxy, or its application code.
If the event does not appear, changing JSON parsing code is premature. Check whether the source event fired, whether the exact destination URL was saved, whether a provider delivery log exists, and whether DNS or network policy blocks the request.
This diagnostic split is the reason to use a RequestBin alternative. The captured request is not merely a payload preview—it is evidence about which part of the delivery path works.
Establish a Controlled Baseline
Before involving a third-party provider, send one request you fully control. The example below includes a query parameter, a custom event header, and nested JSON so each part of the capture can be checked independently.
A successful baseline proves that the endpoint URL is valid and shows how the inspector represents headers and bodies. It also creates a known-good request that can be compared with the provider delivery later.
Use an obviously synthetic identifier. Never paste a real authorization token or customer payload into a public debugging endpoint.
curl --request POST 'https://YOUR_HOST/webhook/YOUR_BUCKET_ID?source=baseline' \
--header 'Content-Type: application/json' \
--header 'X-Test-Event: order.created' \
--data '{"event_id":"evt_test_001","order":{"id":"ord_test_123","total":42}}'$headers = @{ 'X-Test-Event' = 'order.created' }
$body = @{ event_id = 'evt_test_001'; order = @{ id = 'ord_test_123'; total = 42 } } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri 'https://YOUR_HOST/webhook/YOUR_BUCKET_ID?source=baseline' -Headers $headers -ContentType 'application/json' -Body $bodyRead the Capture Layer by Layer
Start with the HTTP method and destination path. A request can contain perfect JSON and still fail because the sender used GET instead of POST or an old endpoint path. Then inspect Content-Type before deciding how the body should be parsed.
Headers usually carry event type, delivery ID, signature, API version, and user-agent information. Query values may select a tenant or environment. The body carries event data, but signature verification may require the exact raw bytes rather than reformatted JSON.
Finally, compare timestamps and stable identifiers across attempts. Repeated delivery IDs or event IDs help distinguish a retry from a separate event. Copy the capture as cURL or PowerShell so the same input can be replayed against a local receiver.
- Method and path: did the sender call the endpoint you configured?
- Content type: should the receiver parse JSON, form data, or plain text?
- Headers: are event, delivery, version, and signature values present?
- Body: do required fields and data types match the provider contract?
- Timing and IDs: is this a new event, a duplicate, or a retry?
Turn Each Signal Into a Next Step
The bin should reduce the search area. Do not treat every missing event as an application bug, and do not treat every captured 200 response as proof that the real receiver processed an event correctly.
| Observed signal | What it establishes | Next investigation |
|---|---|---|
| Nothing arrives | The delivery path to the bin has not been demonstrated. | Check event generation, saved URL, provider logs, DNS, proxy, and firewall. |
| Request arrives with unexpected method | The sender reached the endpoint, but the HTTP contract differs. | Check provider configuration and receiver route constraints. |
| Headers arrive but the body is empty | Transport worked; payload generation or content handling differs. | Check provider event selection, content type, and body-size errors. |
| Bin returns 500 and sender retries | The sender has observable transient-failure behavior. | Record attempt timing and design idempotent receiver processing. |
| Bin receives the event but the app does not | Sender and external route work independently of the app. | Inspect the app URL, TLS, gateway, access logs, parser, and signature verification. |
A request bin proves what reached that bin. It cannot prove that a different endpoint, network path, or application processed the same request.
Test Responses and Retries Deliberately
Request capture tests what the sender transmits. Response simulation tests what the sender does after delivery. Return 200 for a baseline, then choose one failure status supported by the provider documentation and observe the result.
A 429 often represents rate limiting and may include Retry-After. A 500 often represents a temporary receiver failure. A 400 usually represents a request that retries cannot repair, but providers differ, so record actual attempts instead of assuming universal behavior.
Use stable event IDs during retry tests. If the sender retries, a production receiver must make repeated delivery safe through idempotency rather than relying on exactly-once transport.
- Change one response condition at a time
- Record status, response body, attempt count, and delay
- Confirm whether delivery IDs remain stable across retries
- Restore the successful response and verify recovery
Know the Limits and Security Boundary
This hosted tester allows 20 active buckets per normalized source IP and accepts request bodies up to 1 MiB. After a bucket reaches 10,000 requests or 50 MiB, a background worker removes the oldest captures in batches. A history page returns at most 200 requests.
The production retention policy removes inactive buckets after 15 days when cleanup is enabled. Cleanup may be disabled temporarily during a controlled migration, so the endpoint must never be treated as an archive or deletion guarantee without checking the deployed policy.
There are no user accounts or protected buckets. Whoever has the random bucket URL may be able to access its requests or settings. Use synthetic data, remove authorization headers and personal information, and delete the bucket when testing ends.
Know When a Request Bin Is the Wrong Tool
Use a local tunnel when the real application must receive the event during development. Use a self-hosted inspector when test data cannot leave your infrastructure. Use an authenticated team product when access must be limited and audited.
Use a durable queue or event platform when events need guaranteed retention, replay, fan-out, or production processing. A temporary request bin observes HTTP delivery; it is not a substitute for those systems.
For a short investigation, the useful output is a sanitized capture and a reproducible command. Move both into an automated test for your actual receiver, then delete the temporary bucket.
Common questions
Frequently asked questions
- What is a RequestBin alternative?
- It is a temporary HTTP endpoint that records incoming requests so you can inspect webhook methods, headers, query parameters, and bodies without deploying a receiver first.
- Can I test a webhook endpoint online for free?
- Yes. Create a temporary endpoint, send a synthetic request, and inspect the method, headers, query values, body, source IP, and arrival time. Remove credentials and personal data before using any public request bin.
- How does a request bin help diagnose a missing webhook?
- If the request reaches the bin, the sender and public network path work and the defect is likely in the original receiver or its configuration. If it never arrives, investigate the sender event, destination URL, DNS, proxy, firewall, and delivery log before changing application parsing code.
- Can I test retry behavior with this request bin?
- You can configure a response status, content type, and body, then observe whether the sender retries a 429 or 500. Retry rules differ by provider, so record attempts and timing and compare them with that provider’s official documentation.
- What limits apply to this tester?
- The application allows 20 active buckets per source IP, accepts request bodies up to 1 MiB, and starts pruning the oldest requests after a bucket reaches 10,000 requests or 50 MiB. It is not a permanent archive.
Primary sources
Official references
Try it with a real request
Turn the guide into a test.
Open a temporary endpoint, send your payload, and inspect exactly what arrived.
Open the tester