Webhook Guides

Webhook Request Bin

A webhook request bin is a temporary public inbox for webhook requests. Send a provider test event or cURL request to the bin, then inspect the method, path, query string, headers, content type, and payload body.

FastHook keeps the request-bin workflow close to production routing. You can start with quick capture, then move the same webhook pattern into sources, connections, destinations, retries, replay, and delivery evidence.

What a webhook request bin captures

Captured evidenceUse it for
HTTP method and URL pathConfirm the sender is calling the intended endpoint.
Query parametersDebug provider dashboard settings and callback URLs.
HeadersInspect signatures, delivery ids, event names, user agents, and content type.
Payload bodyCompare real provider data with receiver fixtures and docs.
Timestamp and statusProve when the test arrived and whether FastHook accepted it.

Send a webhook to a request bin

Use a request bin when you need a fast endpoint before building the full destination. The first test should verify capture and payload shape; routing and retry behavior can come after the request is understood.

Webhook request bin cURL
curl -X POST "https://hook-xxxxxx.fasthook.io/" \
  -H "Content-Type: application/json" \
  -H "X-Event-Type: customer.created" \
  -d '{
    "id": "evt_bin_001",
    "type": "customer.created",
    "customer": {
      "id": "cus_123",
      "email": "dev@example.com"
    }
  }'

Webhook request bin vs related pages

FastHook has a few similar pages because people search for this workflow in different ways. This page is intentionally focused on the exact phrase webhook request bin: a bin specifically for capturing webhook HTTP requests.

PageBest intent
Webhook request binWebhook-specific request capture and inspection.
Request binGeneric temporary HTTP/request inbox workflow.
RequestBinExact RequestBin-style tool/category query.
RequestBin alternativeComparison against RequestBin.
Webhook receiver onlineOnline receiver page for creating a public URL and receiving traffic.

When the bin should become a route

A webhook request bin is ideal for discovery, but production delivery needs more than capture. Once the provider payload is known, create a durable source and route accepted requests to destinations through connection rules.

  • Use a named source when the provider will keep sending traffic.
  • Add source authentication or provider signature validation before production use.
  • Create destinations for HTTP receivers, Slack alerts, Google Sheets rows, local CLI delivery, or mock APIs.
  • Use filters and transformations once you know the real payload shape.
  • Use retry and replay only after receiver idempotency is clear.

Checklist before leaving the bin

  1. Capture at least one real provider request, not only a hand-written cURL fixture.
  2. Save the event type, delivery id header, content type, and signature header names.
  3. Confirm whether the provider retries failed deliveries and how duplicates are identified.
  4. Create the production FastHook source and destination separately from the temporary bin.
  5. Run one end-to-end test through request, event, and attempt records before going live.

Related guides