Webhook Guides

Webhook Debugger

A webhook debugger should answer one question quickly: where did this delivery stop? Provider dashboards show only part of the story, and receiver logs usually start too late. FastHook keeps the inbound request, routed event, destination attempt, response body, retry state, and replay action in one trace.

Use FastHook as an online webhook debugger when you need to inspect headers, payloads, request paths, source authentication failures, filter misses, destination errors, timeout responses, duplicate retries, or replay behavior without building temporary logging endpoints inside every application.

Webhook debugger evidence ladder from provider request to request record, routed event, destination attempt, receiver state, and recovery. — A useful debugger keeps ingress and delivery evidence separate. First prove what arrived, then prove what was routed and delivered.

What a webhook debugger should show

Question	FastHook record	Fields to inspect
Did the provider reach us?	Request	`status`, `headers`, `body`, `path`, `query`
Was the source accepted?	Request	`verified`, `rejection_cause`, source auth result
Did a route match?	Event	`connection_id`, `destination_id`, ignored/filter state
What did the receiver return?	Attempt	`response_status`, `body`, `requested_url`, `error_code`
Is replay safe?	Event and request history	attempt count, receiver fix, idempotency key, retry scope

Webhook debug online

Online debugging is useful when the provider is already sending real traffic or when a teammate needs a shared trace. Create a FastHook source URL, send a fixture or provider event, then inspect request, event, and attempt records without adding temporary logging code to the receiver.

Fast triage workflow

Find the inbound request in a narrow time range.
Open the request with include=data to inspect payload, headers, query, path, method, and rejection cause.
If the request was accepted, inspect events created from that request.
Open destination attempts for the failed event and read the response body before retrying.
Fix source auth, filters, destination URL, receiver credentials, or receiver code.
Retry one event first. Use request replay only when current routing should re-process the original request.

Debug a webhook with cURL

Find rejected requests

curl "https://api.fasthook.io/v1/requests?source_id=src_q6z62b6py5o79b&status=rejected&from=now-1h&to=now&limit=20&include=data" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID"

Find failed routed events

Find failed events

curl "https://api.fasthook.io/v1/events?status=FAILED&from=now-1h&to=now&limit=20" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID"

Inspect attempts for one event

Inspect 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"

Retry one failed event

Retry event

curl -X POST "https://api.fasthook.io/v1/events/evt_01jv8c4n9p3x7r2t6q5m1k0s8b/retry" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID"

Common debugger findings

No request: the provider is using the wrong URL, environment, or endpoint path.
Rejected request: method, source auth, provider signature, or source status stopped ingress.
Accepted request, no event: route filters or connection state prevented delivery.
Failed attempt: destination URL, credentials, payload contract, rate limit, timeout, or receiver code failed.
Repeated side effects: provider retry, FastHook retry, or operator replay found a non-idempotent receiver.

When to use request replay

Request replay runs the original accepted request through current routing. Use it when filters, connections, transformations, or destinations changed after the request arrived. If only one destination attempt failed, retry the existing event first so the blast radius stays small.