Webhook Guides

Webhook Site

A webhook site gives you a public place to receive webhook requests, inspect payloads, and forward accepted events to real receivers. It is useful for provider setup, debugging, local development, staging, and incident recovery.

FastHook is a webhook site built for operational traffic: every request can become a traceable event with destination attempts, response bodies, retry state, and replay controls.

Webhook site workflow from provider to FastHook source, connection, and destination.
Use one stable webhook site URL for provider ingress, then route accepted traffic to the receivers that need it.

What to expect from a webhook site

  • Public HTTPS URLs that providers can call.
  • Header, query, path, body, status, and rejection evidence.
  • Routing from one source to one or many destinations.
  • Local testing through CLI destinations without exposing localhost.
  • Retry and replay controls when receiver code or credentials are fixed.

Webhook site use cases

Use a webhook site when you are setting up a provider for the first time, building a new receiver, debugging a failed delivery, sharing evidence with another engineer, or sending real provider traffic to a local machine through a tunnel. The point is to keep the public provider URL stable while the downstream receiver can change.

FastHook is also useful after the first test succeeds. Production teams need to know which events arrived, which branch routed them, whether the receiver responded, and whether replay would be safe. A webhook site that only shows the last payload is helpful for demos; a webhook site with attempts and recovery controls is useful for operations.

Create a webhook site source

Create webhook site source
curl -X POST "https://api.fasthook.io/v1/sources" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Webhook site inbox",
    "type": "WEBHOOK",
    "config": {
      "auth_type": null,
      "allowed_http_methods": ["POST", "PUT", "PATCH", "DELETE"]
    }
  }'

From inbox to production route

  1. Create a source URL and send a test event.
  2. Inspect request headers, path, query params, and body.
  3. Add source authentication once the provider secret is known.
  4. Create a destination for the receiver or local CLI tunnel.
  5. Add connection filters so only intended event families are delivered.
  6. Use retry and replay only after the receiver is idempotent.

Webhook site safety notes

  • Do not send production secrets to a public test inbox you do not control.
  • Use separate sources for provider testing and production events.
  • Delete or disable stale test sources after provider setup is complete.
  • Keep personally sensitive payloads out of screenshots and shared support notes.

Debugging from the webhook site

Start with the request record. If no request appears, the provider is using the wrong URL, environment, or network path. If the request is rejected, inspect method, source status, and authentication. If the request is accepted but no destination attempt appears, inspect connection filters and disabled routes. If an attempt failed, read the receiver status and response body before retrying.

This keeps debugging grounded in evidence. The webhook site should tell you where the delivery stopped instead of making every receiver add temporary logs during an incident.

Related guides