Skip to content

Webhook inspector

A private URL that records every request live. Verify signatures, set response rules, simulate failures, forward and share.

Get a webhook URL

Point any service at it – a payment provider, GitHub, a form, your own code – and watch the requests arrive here as they happen.

What this tool checks

The webhook inspector gives you a capture URL such as https://thenetworkery.com/h/abc123def456. Any request sent to it, with any method and path after it, appears on your bin's page within seconds: method, path, query string exactly as sent, headers, body, size and sender IP. Headers added by our CDN and proxy are kept apart.

  • Bodies up to 512 KB are stored; the rest is cut off, but the full size is recorded. Binary bodies are shown as a hex dump; for multipart uploads, files are recorded by name, size and type only.
  • Each bin accepts 120 requests a minute; above that the sender gets 429.
Without an account Free account
Webhook URLs at a time 3 10
Requests kept per URL last 500 last 2,000
URL lifetime 7 days 30 days (3 can be kept without expiry)
Response rules per URL 5 20
Auto-forwards per minute 30 60
Custom name, email alerts – yes

Without an account, bins are tied to your browser session; the private link on the bin page opens it on other devices, and anyone with it has full control. Expired bins are deleted with their requests.

It checks signatures from Stripe, GitHub, GitLab (token or signing token), Bitbucket, Shopify, Slack, Twilio, Paddle Billing, Standard Webhooks (Svix), Zoom, Linear, Square, SendGrid, Mailgun, Discord, Twitch, Intercom, HubSpot, Jira, Calendly, Typeform, or any HMAC scheme. The check runs in your browser: the secret is never sent to our server. Each sender's scheme, timeouts, retries and source IP ranges are in the webhook reference.

Bins also work without a browser: the REST API (POST /api/v1/webhooks, then read requests with the bin's key), the MCP server for AI assistants (create_webhook_url, list_webhook_requests, get_webhook_request).

Reading the results

The list shows each request newest first, with the sender and event when recognised ("Stripe · payment_intent.succeeded"), the status it was answered with and what produced it: the default response, a rule, or a simulated failure. Filter by path, method, header, body text or time; Search stored requests also looks through older ones. The compare button shows two requests side by side, with JSON compared key by key.

Select a request for:

  • How the sender delivers – for a recognised sender, its timeout, retry behaviour and ordering from our webhook reference, and whether the request came from the sender's published IP ranges. That last check is informational: a proxy or tunnel in front of the bin changes the address.
  • Verify signature – the provider is picked from the headers; paste the signing secret. The result is Valid, Invalid, Signature header missing or Timestamp too old (outside the provider's tolerance, measured from when we received it). On failure it names the likely cause.
  • Generate types – a TypeScript interface, JSON Schema or Python dataclasses from a JSON body.
  • Body, Headers, Copy as curl and Replay to another URL (public addresses only, ports 80, 443, 8080 or 8443, no redirects).

What the URL answers is the default response: a status from 200 to 599, a content type (never HTML) and a body up to 64 KB. Allow browser calls (CORS) answers preflight requests itself.

Response rules are tried from the top; the first match answers. A rule can require a method, a path (exact, prefix, or a pattern with * and **), a header value, body text, or a JSON value such as $.type equal to refund, and sets its own status, body and safe extra headers. A bin can never set cookies or redirect to another site.

Failure simulation tests a sender's retries: fail the first N requests, fail a percentage at random, add a delay, or answer like a timeout. Delays stop at 10 seconds, and only a few requests can wait at once; beyond that the answer goes out at once, marked "delay skipped".

Auto-forward sends every captured request to one public URL right after the sender has its answer, with a 5-second timeout. Forwarded requests carry X-Networkery-Forwarded and are never forwarded again.

Under Sharing and lifetime you can create a read-only link, and with an account give the URL a custom name such as /h/my-shop-orders, keep it without expiry, and get email alerts (at most one every 10 minutes, never with the body).

Common problems and fixes

No requests arrive

Check the sender uses the exact URL, including https://. Many providers only send after an event or a "send test event" button. Expired bins answer 404.

The provider marks the delivery as failed

Most providers expect a 2xx status quickly. Check no rule or failure simulation is still switched on.

The signature check fails

Usually the secret is wrong (Stripe's CLI and dashboard secrets differ), or your code hashes re-serialised JSON instead of the raw body. If the check here says Valid but your server rejects it, read the raw body before parsing. Twilio and Square also sign the URL, which must match exactly.

A browser request fails with a CORS error

Enable "Allow browser calls (CORS)" and save.

FAQ

How do I test a webhook?

Create a URL, paste it into the service's webhook settings and trigger an event. Or send one yourself:

curl -X POST -H 'Content-Type: application/json' -d '{"hello":"world"}' https://thenetworkery.com/h/abc123def456
Is it safe to paste my webhook secret here?

The signature is calculated in your browser with the Web Crypto API; the secret is not sent to our server. Use a test-mode secret where the provider offers one.

How long are webhook requests kept?

The newest 500 requests (2,000 with an account), for 7 days (30 with an account, or until you delete up to 3 kept URLs).

Can I share webhook requests with a colleague?

Yes: a read-only link shows the requests without the controls, and you can replace or turn it off at any time.

How do I test the sending side?

The MCP client tester does this for MCP clients.