Can I test a webhook without exposing my local machine?

Yes — that is the point of a mock receiver. The provider calls a public URL that is not your laptop, so you can capture and read deliveries without a tunnel and without opening a port.

Will I see the signature headers the provider sends?

Yes. The inspector records the headers of each delivery, including provider signature headers such as Stripe-Signature and X-Hub-Signature-256. Credential headers like Authorization, Cookie and X-Api-Key are stored redacted, and only the first value of a repeated header is kept. Verifying a signature is still your handler's job — the mock accepts whatever arrives.

Can the endpoint reply with a value taken from the request?

Yes. Request tokens let the response echo part of the incoming body, which is what handshakes like Slack's url_verification require before they will enable an endpoint.

Test a webhook receiver

Catch incoming webhook calls and inspect their headers and body in real time.

To test a webhook receiver you need a public URL the sender can actually reach, which rules out localhost. A mock webhook endpoint gives you that URL immediately: it accepts the POST, returns the acknowledgement the provider expects, and records the full request so you can read the headers and body the sender really transmitted — as opposed to the ones the documentation says it does.

Why can't the provider just call localhost?

A webhook is the provider's server calling yours. http://localhost:3000 means "this machine" on the provider's side too, so their call never leaves their network. Tunnelling tools solve this by exposing your laptop; a mock endpoint solves it by removing your laptop from the loop entirely.

That difference matters early on. Before your handler exists, what you actually need to know is what the provider sends — which headers, which body, which content type. A mock answers that question in one delivery, and you write the handler against the recorded request instead of against the documentation's example.

What should the endpoint reply to the sender?

Almost every provider treats any 2xx as success and everything else as failure worth retrying, so return 200 quickly and keep the body small. Stripe retries for days on non-2xx; GitHub records the failure in the delivery log. Both punish a slow handler as harshly as a broken one.

Some providers want more than a status code. Slack's Events API will not enable an endpoint until it echoes back the challenge value from the verification request. If your endpoint has to answer with something derived from the request, mock that echo rather than a fixed body.

How do you see what the sender actually sent?

Open the inspector for the mock and every delivery is listed with its method, headers, body and timestamp. This is the part that is hard to get any other way: signature headers, the exact content type, and the difference between what the provider documents and what it transmits.

Trigger a real event from the provider's dashboard rather than sending yourself a hand-written POST. A payload you wrote yourself confirms your assumptions; a payload the provider sent corrects them.

Two deliveries of the same event are worth comparing side by side. Providers redeliver after a failure, and the retry is not always byte-identical to the first attempt — if the provider sends a delivery ID header, that is what your idempotency key should be built from, not a hash of the body.

What usually goes wrong?

Testing with a payload you invented. It proves your parser handles your own JSON, which was never in doubt.
Returning 200 before the work is done — or after. Acknowledge fast, then process asynchronously. Providers time out well before a slow handler finishes.
Ignoring redelivery. Retries mean the same event arrives twice. Handlers must be idempotent, and sending the same delivery twice is how you prove it.
Assuming the mock verifies signatures. It does not. Signature checking is your handler's job and has to be tested against the real sender.

When to use this

Integrating a third-party webhook (Stripe, GitHub, a payment provider) means you need a URL to point it at — and a way to see exactly what it sends. Create a POST mock, give its URL to the provider, and watch every call land in the live request inspector: method, headers, query, body.

Create the mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "response_body": "{\"received\":true}"
}'

Call it

curl -X POST -H 'Content-Type: application/json' -d '{"event":"payment.succeeded"}' https://quickmock.dev/m/<slug>

Open the mock page and paste its admin token to watch incoming method, headers, query, and body in the private live inspector.

What you get

{"received":true}

FAQ

Can I test a webhook without exposing my local machine?: Yes — that is the point of a mock receiver. The provider calls a public URL that is not your laptop, so you can capture and read deliveries without a tunnel and without opening a port.
Will I see the signature headers the provider sends?: Yes. The inspector records the headers of each delivery, including provider signature headers such as Stripe-Signature and X-Hub-Signature-256. Credential headers like Authorization, Cookie and X-Api-Key are stored redacted, and only the first value of a repeated header is kept. Verifying a signature is still your handler's job — the mock accepts whatever arrives.
Can the endpoint reply with a value taken from the request?: Yes. Request tokens let the response echo part of the incoming body, which is what handshakes like Slack's url_verification require before they will enable an endpoint.

Build your own

Create a mock

Ready-made templates for this: Mock a Stripe webhook payload, Mock a Shopify order webhook, Mock a GitHub push webhook

Related guides

← All guides

Last updated: 2026-09-08