Webhook Guides

Webhook Inspector

A webhook inspector captures an incoming HTTP request and makes the raw evidence readable: payload body, headers, method, path, query string, content type, source authentication result, and provider delivery ids.

FastHook uses that inspector workflow as the first step in a durable webhook trace. You can inspect what arrived before routing, then keep the same request connected to events, destination attempts, retries, and replay when the integration moves beyond a quick test.

What a webhook inspector shows

Request fieldWhat to check
Payload bodyConfirm the event shape, required fields, nested objects, and fixture values.
HeadersFind event type, delivery id, signature, timestamp, content type, and provider metadata.
Path and query paramsVerify environment, tenant, route, challenge, or provider callback values.
Method and statusCheck whether the sender used POST and whether source auth accepted the request.
Raw request timingCorrelate provider dashboard timestamps with FastHook request evidence.

Inspect a webhook request

Send a request to inspect
curl -X POST "https://hook-xxxxxx.fasthook.io/orders?source=qa" \
  -H "Content-Type: application/json" \
  -H "X-Event-Type: order.created" \
  -H "X-Delivery-Id: del_inspect_001" \
  -d '{
    "id": "evt_inspect_001",
    "type": "order.created",
    "data": {
      "order_id": "ord_410",
      "total": 4900,
      "currency": "USD"
    }
  }'

Inspector vs receiver vs debugger

Use a webhook inspector when the job is to read exactly what a sender posted. Use a receiver when the main need is a public URL that accepts traffic. Use a debugger when the request was accepted but routing, delivery, retry, or replay behavior needs diagnosis.

Intent pageBest fit
Webhook inspectorInspect payloads, headers, paths, query params, and source verification evidence.
Webhook receiver onlineCreate a public URL and receive webhook or HTTP requests online.
Webhook testerSend fixtures through a source URL and prove testing behavior across destinations.
Webhook debuggerDiagnose failed routing, destination attempts, response bodies, retries, and replay.

Inspection checklist

  1. Create or reuse a FastHook source URL for the provider, app, or cURL test.
  2. Send a fixture or real provider event to the source URL.
  3. Open the captured request and inspect method, path, query string, headers, and body.
  4. Check source verification, rejection cause, content type, event type, and delivery id.
  5. Route accepted requests to mock, staging, local, or production destinations only after the evidence is clear.

Headers and body evidence

The payload usually explains what changed, but the headers often explain how to handle it. Provider event names, delivery ids, signatures, timestamps, retry counters, and content types usually live outside the JSON body.

FastHook keeps both sides visible. That makes it easier to compare a provider dashboard delivery with the request your integration actually received before writing filters, transformations, or receiver code.

  • Compare provider delivery ids across provider logs, FastHook, and receiver logs.
  • Inspect signature and timestamp headers before changing source authentication.
  • Use path and query values to separate environments or tenants.
  • Inspect rejected requests instead of only successful deliveries.

From inspection to routing

A request inspector should not become a dead end. Once the payload and headers look right, FastHook can keep the same source URL and send accepted events through connections to HTTP receivers, local CLI destinations, mock APIs, Slack alerts, Google Sheets rows, or other operational destinations.

Related guides