Webhook Guides

Webhook Sender

A webhook sender delivers event payloads to another HTTP endpoint. FastHook sends webhooks after an accepted source request matches a connection and creates a routed event for a destination.

Use FastHook when you want outbound delivery to include attempt logs, response bodies, destination auth, retries, replay, and rate limits instead of a one-off POST with no recovery trail.

Webhook sender delivery lifecycle from request capture to routed event and destination attempt.
FastHook sends routed events to destinations and stores every delivery attempt for debugging and recovery.

What FastHook sends

  • Accepted source requests routed through active connections.
  • Transformed payloads when a connection rule changes body shape or content type.
  • Destination auth such as custom headers, OAuth tokens, or FastHook delivery signatures.
  • Retry attempts for configured status codes, network failures, timeouts, or manual recovery.

Sender modes

FastHook can send to production HTTP APIs, staging endpoints, localhost through the CLI tunnel, mock receivers for safe testing, Google Sheets for operational review, or Gmail for human notification workflows. The sender behavior is attached to the destination, so one receiver can be reused by several routes without duplicating credentials or rate limits.

This is different from a disposable webhook sender form. A disposable sender can POST a payload once. FastHook sends from recorded events, keeps delivery attempts, and lets you retry after the receiver returns a 500, times out, or rejects the request because a custom header is wrong.

Create a sender destination

Create HTTP destination
curl -X POST "https://api.fasthook.io/v1/destinations" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "orders-webhook-sender",
    "type": "HTTP",
    "config": {
      "url": "https://api.example.com/webhooks/orders",
      "http_method": "POST",
      "auth_type": "CUSTOM_HEADER",
      "auth": {
        "header_name": "x-api-key",
        "value": "receiver-secret"
      }
    }
  }'

Delivery headers and receiver trust

Receivers often need to know that a request came through the webhook sender and not from a random client. FastHook supports destination authentication modes for that boundary. Use CUSTOM_HEADER when the receiver expects a static shared secret, or FASTHOOK_SIGNATURE when the receiver should verify a timestamped HMAC signature over the exact outbound body.

Send a test payload through the route

Send test webhook
curl -X POST "https://hook-xxxxxx.fasthook.io/" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "evt_sender_test_1",
    "type": "order.created",
    "data": {
      "order_id": "ord_102",
      "total": 4900
    }
  }'

Inspect sender attempts

Inspect destination attempts
curl "https://api.fasthook.io/v1/attempts?event_id=evt_01jv8c4n9p3x7r2t6q5m1k0s8b&order_by=created_at&dir=desc&limit=20" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID"

Webhook sender troubleshooting

  • No attempt appears: confirm the source request was accepted and a connection matched.
  • 401 or 403: inspect destination auth, custom header names, OAuth tokens, or signatures.
  • 404 or 405: confirm the destination URL, path forwarding behavior, and HTTP method.
  • Timeout: make the receiver acknowledge faster or route heavy work to a background job.
  • Duplicate side effects: store provider event ids or FastHook event ids before processing.

When to use a sender instead of direct code

Sending webhooks directly from application code is reasonable for low-risk notifications. Use a sender layer when failed delivery needs to be recoverable, several routes share one receiver, receiver credentials rotate, or operators need to retry events without deploying code. A sender also helps when local developers need the same provider traffic delivered to localhost through an authenticated tunnel.

Keep business idempotency in the receiver. The sender can retry, but only the receiver knows whether an order, ticket, deployment, or message has already been created.

Related guides