Webhook Inspectorserver-backed
Get a temporary URL, point a service at it, and read every request it sends.
Checking for an existing endpoint…
Reference
How to use it
Create an endpoint, copy the URL, and paste it wherever a service asks for a webhook destination — Stripe's dashboard, a GitHub repository's settings, a Discord integration, or your own code. Every request that arrives appears in the list within a few seconds, with its method, headers, query string and body.
The endpoint answers 200 with a small JSON acknowledgement to everything. That matters for providers that retry on any non-2xx response and disable a webhook after enough failures.
Lifetime and limits
| Limit | Value |
|---|---|
| Endpoint lifetime | 60 minutes from creation. It cannot be extended — create a new one. |
| Requests kept | 50. Once full, further requests are refused with 409 rather than pushing older ones out. |
| Body captured | 64 KB. Larger bodies are stored truncated, and the panel says so and reports the true size. |
| Rate | 120 requests per minute per sending IP address. |
Who can see what
Anyone who knows the URL can send to it — that is unavoidable, since the whole point is that a third party posts to it. Reading what was captured is different: it requires a token that was generated when you created the endpoint, returned to you once, and stored only in this browser. The server keeps a hash of it, so nobody reading the store can take over a live session.
The practical consequence is that a session does not follow you to another browser or another device. Clearing site data ends it. That is the trade for not making every captured payload readable by anyone who guesses an id.
Rotate and delete
Rotate issues a new URL for the same session and stops the old one immediately, carrying the captured requests across. It is what to reach for when a URL has been pasted somewhere it should not have been. Delete removes the endpoint and everything it captured at once, rather than waiting for the hour to run out.
Replay
Replay sends a captured request again — same method, headers and body — to a destination you type. It is the fastest way to re-run a delivery against a staging service without waiting for the provider to send another one.
Two caveats. The destination must be a public address; a tunnel URL works, plain localhost does not. And signature headers are replayed exactly as captured, so a receiver that verifies a timestamp inside the signature will reject the replay as too old — correctly.
Credential headers are the exception, and they are held back by default. Authorization, Cookie and X-API-Key belong to whoever sent the original request, and the destination is one you type — so sending them is a switch you turn on, not something replay does quietly. The panel names exactly which headers are affected when a captured request carries any. Signature headers are not in that set, because replaying those unchanged is the point.
What is stored, and what is not
Captured requests are held on R3X infrastructure for up to an hour and then deleted. Sender IP addresses are truncated before storage. Nothing in a request body is ever parsed as code, evaluated, or used to build a command — bodies are kept as bytes and classified, and binary payloads are stored base64 and never rendered.
Do not point production traffic at this. It is a debugging surface with a public URL and a one-hour memory, and it is exactly as trustworthy as that description sounds.
Questions
- How do I test a webhook without deploying anything?
- Create an endpoint here, paste the URL into the provider's dashboard — Stripe, a repository's webhook settings, Shopify, Discord — and trigger an event. The full request appears within a few seconds with its headers, query string and body, and you can generate curl or fetch code to replay it against your own service.
- How long does the URL last?
- 60 minutes, and it holds up to 50 requests. It cannot be extended — create a new one. Everything captured is deleted when the session expires.
- Can anyone else read what my endpoint captured?
- Only someone holding the manage token, which was generated when you created the endpoint and is stored in this browser alone. The server keeps only a hash of it. Anyone who knows the URL can send to it — that is unavoidable — but sending and reading are separate.