Webhook Guides

Webhook Tester for Routing and Replay

Live smoke test

Send a real webhook in under a minute

Create a temporary FastHook endpoint, choose a realistic event, and confirm that the request was captured.

No login. The temporary endpoint expires automatically after one hour.

A webhook tester should prove more than "the endpoint received a POST." Production webhooks fail because of signatures, headers, routing rules, duplicate events, slow receivers, malformed payloads, and retry behavior.

FastHook gives you a public source URL for test traffic, stores the request, creates routed events, delivers to a Request Bin, local CLI, or real HTTP destinations, and records every attempt. That makes the same test useful before and after the integration goes live.

Test matrix

TestWhat it catches
Valid payloadBasic source capture and destination delivery.
Missing signatureSource auth rejection behavior.
Wrong event typeFilter and routing mistakes.
Duplicate event idReceiver idempotency gaps.
Receiver 500 or timeoutRetry and failed delivery behavior.

Save a real webhook as a repeatable test

Hand-written JSON is useful for a smoke test, but a captured provider request includes the method, path, headers, payload shape, and verification result that actually reached your source. Open that request and save it as a named fixture instead of rebuilding the edge case for every test run.

Capture a real webhook, inspect its verification evidence, and save the request as a named fixture for repeatable testing.
  1. Send a provider test event or cURL request to a FastHook source URL.
  2. Open the captured request and verify its method, headers, body, path, and source-auth result.
  3. Select Save fixture and give the case a name plus the expected result.
  4. Open Saved events, choose one destination, and run the fixture again after each receiver change.

Fixture examples worth keeping

FixtureExpected assertion
Successful paymentThe destination accepts the payment event once and records the expected side effect.
Invalid signatureThe source rejects the request before routing and preserves verification evidence.
Duplicate eventReplaying the same delivery id does not create a second business side effect.

Send a test event

Webhook tester cURL
curl -X POST "https://hook-xxxxxx.fasthook.io/" \
  -H "Content-Type: application/json" \
  -H "X-Event-Type: order.created" \
  -d '{
    "id": "evt_test_001",
    "type": "order.created",
    "order": {
      "id": "ord_123",
      "total": 4900,
      "currency": "USD"
    }
  }'

Where to deliver tests

  • Use an HTTP Destination that points to a Request Bin or test receiver for safe inspection.
  • Use CLI destination to forward provider traffic to localhost.
  • Use HTTP destination for staging or production receivers.
  • Use Google Sheets Action when QA or support needs visible rows.
  • Use Gmail Action when humans need low-volume notifications.

What to inspect

  1. Request method, path, query, headers, and body.
  2. Source verification status and rejection reason.
  3. Connection filters and transformations.
  4. Destination attempt status, latency, and response body.
  5. Retry count and replay safety before redelivery.

A good tester stores evidence

A disposable test URL is useful, but a production-grade webhook tester should preserve enough context to answer an incident question later. The request body by itself cannot explain whether a route matched, why a receiver returned 400, or whether a retry created a duplicate side effect.

FastHook keeps the inbound request linked to routed events and destination attempts. That means the same tool can validate a first cURL request, test a real provider delivery, and later prove why one branch failed while another succeeded.

  • Store rejected requests, not just accepted requests.
  • Keep response bodies for failed destination attempts.
  • Record retry attempts separately from the original delivery attempt.
  • Keep event ids and provider delivery ids visible for correlation.

Provider test events

After a cURL smoke test passes, use provider-generated test events whenever possible. Provider tests catch real signature headers, real content types, dashboard configuration mistakes, and event shapes that are easy to miss in hand-written JSON fixtures.

Related guides