Guide

Request Trace Page

The request trace page is the fastest way to answer what happened to one webhook after it reached FastHook. It starts with the original inbound request and follows every branch created from that request.

Use it when a provider shows a webhook was delivered, a customer says nothing happened, a destination failed, a filter ignored a branch, or a transformation changed the payload before delivery.

Instead of jumping between Requests, Events, Attempts, and transformation execution pages, the trace view collects the whole path into one timeline.

What The Trace Shows

A trace is centered on one req_* record. FastHook loads the original stored request, the events created by connection routing, ignored branches, delivery attempts, transformation executions, and a timestamped timeline.

This keeps the original request separate from transformed event data. When a transformation runs, the trace shows both the original event data and the transformed event data so you can prove exactly where the payload changed.

  • Inbound method, path, query, headers, body, source_id, verified state, and original_event_data_id.
  • Every routed event with connection_id, destination_id, event_data_id, status, response_status, and failure context.
  • Ignored branches such as filtered or cancelled route results.
  • Delivery attempts with requested_url, HTTP method, response status, response body, latency, and error code.
  • Transformation executions with logs, before payload, after payload, and transformed_event_data_id.
  • A single timeline sorted by request, event, transformation, and attempt timestamps.

Dashboard Workflow

  • Open Requests in the FastHook dashboard.
  • Select the request you want to investigate.
  • Click Trace in the request inspector.
  • Start with the inbound request block to confirm provider payload, headers, method, and path.
  • Read the timeline to see which routing and delivery steps happened in order.
  • Open each routed event branch to inspect transformations and attempts.
  • Use modified replay, exact request replay, or event retry only after the trace proves what failed.

API Workflow

Automation can fetch the same evidence with one Control API call. This is useful for internal incident tools, support dashboards, and AI debugging workflows that need a compact request path object.

Fetch request trace
curl "https://api.fasthook.io/v1/requests/req_01jv8c3m7b2p4q9x6r5t1n0k8s/trace" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_xxx"

Debugging Patterns

The trace page is most useful when you read it from left to right: source capture, route fan-out, transformation, destination attempt, receiver response. That order keeps you from retrying before you know whether the issue is ingress, routing, payload shape, delivery, or downstream processing.

  • If the request is rejected, fix source method, auth, timestamp, provider signature, or source state.
  • If the request is accepted but has no routed events, inspect enabled connections, source_id ownership, and route filters.
  • If a branch is ignored, inspect the ignored reason and compare it with filter and deduplication rules.
  • If a transformation changed the payload incorrectly, fix the transformation and replay a controlled request.
  • If the attempt failed, fix the destination URL, auth, receiver timeout, or receiver validation before retrying.
  • If the attempt succeeded but the app did not process, debug receiver idempotency, queues, and application logs.

When Trace Is Better Than Separate Pages

  • You are investigating one customer report and need the complete evidence chain.
  • A provider dashboard only shows 200 OK and you need downstream proof.
  • A branch passed filters but the destination response body explains the failure.
  • A transformation changed a field and the receiver rejected the transformed shape.
  • A teammate needs one compact page before deciding between event retry and request replay.

When Separate Views Are Better

Use Requests, Events, Attempts, Metrics, and bulk operations when you need to compare many records or recover an incident at scale. Trace is intentionally focused on one request.

  • Use Requests for time-range triage across many inbound calls.
  • Use Events when one destination is failing across many requests.
  • Use Attempts when you need a paginated list of receiver responses.
  • Use Metrics when you need rate, failure, or queue shape over time.
  • Use bulk operations when you need controlled recovery for many matching requests or events.

Next