Webhook Tester for Rails Apps

A public URL that accepts any request, every delivery shown as it lands, and the route and controller action that would handle it in your own app.

All tools

Start an endpoint

We mint a URL that accepts any method and records what arrives. Point a provider's test button at it, or send one yourself with curl.

Requests sent to this URL are stored on our servers for 6 hours, and anyone holding the URL can read them. Send test payloads through it, not live customer data.

Why a provider cannot reach localhost:3000

Your development server listens on your own machine. When a payment gateway or a repository host posts an event, it resolves a public hostname and opens the connection from its own network - and 127.0.0.1 there means its own loopback, not yours. That is why a webhook you have wired correctly still never arrives while you are working locally. A tunnel is one answer, but a tunnel hands you a URL and no record: when a delivery goes wrong you are left reading your own logs for a request that may never have been made. This page gives you the URL and the record. Paste it into the provider's dashboard, press their test button, and the delivery lands here with the method, the headers, the query string and the body it actually sent - which is often not the one in their documentation.

The controller that receives it

A webhook is a POST from a stranger, so forgery protection will reject it: the receiving controller needs skip_forgery_protection, or a base class that never had it. Read the payload with request.raw_post rather than params, because a signature is computed over the exact bytes and params has already parsed, re-ordered and type-cast them. Answer quickly - providers time out in a few seconds and retry, so hand the payload to a job and return head :ok instead of doing the work inline. And expect the same event twice: a retry after a timeout you did in fact answer is ordinary, so key your side effects on the provider's event id and make the second delivery a no-op.

Replaying a captured request against your own app

Once a delivery is here you can stop waiting on the provider. Open the row, copy the received URL and the body, and send the same thing at your own server with curl - bin/rails s, the route from the snippet beside it, and you are debugging against a real payload with no network in the way. The body is worth keeping too: drop it into spec/fixtures and a request spec that posts it to your receiver will catch the day the provider renames a field. That is the part a tunnel cannot give you, because what it forwarded is gone the moment the tunnel closes.

Questions about testing webhooks

Yes - that is what it is for. The endpoint answers any method with 200, so a provider's send-test-event button sees a healthy receiver and records a success. Add path segments after the URL if you want to tell two subscriptions apart: everything after the token is recorded and shown, and the Rails route in each row is built from it.

Open the row, copy the body, and post it at your own server on port 3000. The route and controller snippets in the same row give you the two halves of the receiving end, so the address you post to exists before the first real delivery does.

No. This records a delivery, it does not validate one. The signature header arrives with everything else and is listed with the other headers, which is useful for checking the provider sends the header you expect - but computing the digest needs your signing secret, and that belongs in your own app rather than on a page anyone can open.

An endpoint and everything sent to it are deleted 6 hours after it is created, and it stops accepting requests at the same moment. Until then anyone holding the URL can read what arrived, because the URL is the only key there is. Bodies over 64 KB are not stored at all. Send test payloads through it, not live customer data.

Start creating your next app now