Webhook Guides

Webhook Tester

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 mock, local, or real 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.

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 MOCK_API for a safe destination with no external side effects.
  • Use CLI destination to forward provider traffic to localhost.
  • Use HTTP destination for staging or production receivers.
  • Use Google Sheet destination when QA or support needs visible rows.
  • Use Gmail destination 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