Stop Adding console.log to Production Just to See What a Webhook Sent

You've integrated a payment gateway, a CI provider, or a SaaS product that sends webhooks — and now something's not working. The payload isn't arriving the way the docs say it should, a header is missing, or the signature verification keeps failing. So what do you do?

If you're like most of us, you reach for one of these:

• Add a console.log(req.body) and redeploy, just to see one request
• Spin up ngrok and wire up a throwaway Express route
• Dig through your provider's dashboard hoping they log raw payloads
• Set a breakpoint and pray the webhook fires again before you give up

All of that is overhead for a problem that's really simple: you just need to see, once, exactly what a request looks like — method, headers, query params, and body — without touching your codebase or your infrastructure.

The actual problem: webhooks are invisible by default

Unlike a normal API call you make yourself, a webhook is something sent to you. You don't control the request, and by the time it hits your handler, you've usually already written code that assumes a shape for the payload. If that assumption is wrong, you're debugging blind — adding logging, redeploying, and waiting for the next event to fire, one guess at a time.

This gets worse with:

• Signature verification (Stripe, GitHub, Shopify, etc.), where you need to see the exact raw headers and body to debug a mismatch
• Third-party integrations you don't own, where you can't just add a log line on the sending side
• Local development, where the sender can't even reach localhost in the first place

A disposable inbox for HTTP requests

The Webhook / Request Bin tool on samtoolkit.com solves this the same way tools like RequestBin or webhook.site do, but as a free, no-signup utility: click Create a new bin, get a unique URL back, and point your webhook or integration at it.

From there, every request that hits that URL is captured and shown to you live — method, full headers, query params, and body — as it arrives. No redeploying, no ngrok tunnel, no guessing.

Typical workflow:

1. Create a bin — you get a unique, disposable URL instantly
2. Point the webhook at it — swap it into your provider's dashboard temporarily, or use it while building the integration before your real endpoint exists
3. Trigger the event — a test payment, a push to a repo, whatever fires the webhook
4. Inspect the raw request — see the exact headers, body, and query string the provider actually sent, not what the docs say they send
5. Fix your handler with the real shape of the data, then point the webhook back at your actual endpoint

Where this saves the most time

• Signature/HMAC verification bugs — compare the raw header casing and body bytes the provider sent against what your code is hashing
• "Which fields actually come through" — some providers document an idealized payload that doesn't match what ships in edge cases (retries, test mode, optional fields)
• Building an integration before the backend route exists — capture real traffic first, write the handler to match, instead of guessing at the shape upfront
• One-off debugging — you don't need to leave a debug route sitting in your production codebase for a problem you'll only debug once

Since it's just a URL, it works with anything that can make an HTTP request — not just webhooks. Testing a client's outgoing API calls, checking what a form action actually submits, verifying a redirect includes the right query params — all the same tool.

---

Part of samtoolkit.com — ~30 free, privacy-first developer utilities. Bins are ephemeral and not tied to an account; don't send anything sensitive through a temporary debugging URL.