Replay with Modifications

What Can Be Changed

A modified request replay can override the HTTP method, path, query string, headers, and body used for the replayed request. The replay stays tied to the original request id through retry metadata, but the payload stored for the new replay is the edited payload.

FastHook keeps this scoped to the original source. You cannot use modified replay to move a request to another source; create a new test request or route if the source boundary should change.

• method: GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS.
• path: a normalized path such as /stripe/replay-test.
• query: a raw query string with or without the leading question mark.
• headers: a JSON object of replay headers after FastHook header sanitization.
• body: a string, JSON object, array, number, boolean, or null. The stored replay body is limited to 10 MB.

{
  "modifications": {
    "method": "POST",
    "path": "/stripe/replay-test",
    "query": "dry_run=true",
    "headers": {
      "content-type": "application/json",
      "x-debug-replay": "true"
    },
    "body": {
      "type": "invoice.paid",
      "replay_test": true
    }
  }
}

Exact Replay vs Modified Replay

Exact replay sends the stored request data again through current routing. Modified replay first writes an edited request envelope, then queues replay from that edited envelope.

Both paths create replay evidence. The important difference is intent: exact replay is recovery for a known request, while modified replay is a debugging and validation tool for a changed receiver contract.

• Use exact replay when the original request was correct and the receiver is healthy again.
• Use event retry when only one destination branch failed after routing was already correct.
• Use modified replay when you need to adjust a request field before sending it again.
• Use bulk replay for large exact recovery windows after a single replay has succeeded.
• Do not use modified replay to bypass receiver idempotency or source trust boundaries.

# exact replay
curl -X POST "https://api.fasthook.io/v1/requests/req_xxx/retry" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_xxx"

# modified replay
curl -X POST "https://api.fasthook.io/v1/requests/req_xxx/retry" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "modifications": {
      "method": "POST",
      "path": "/debug/fixed-path",
      "headers": {
        "content-type": "application/json"
      },
      "body": "{\"ok\":true,\"source\":\"modified-replay\"}"
    }
  }'

Dashboard Workflow

The dashboard exposes modified replay from the Requests inspector. Open a request, inspect its current method, path, headers, and body, then open the replay editor and change only the fields needed for the test.

After the replay is queued, inspect the new request and downstream events before repeating the action. Treat modified replay like a production operation when the destination can create real side effects.

• Open Requests and select the captured request.
• Review the original request data and destination attempts.
• Click Modify replay in the request detail panel.
• Edit method, path, query, headers JSON, or body.
• Click Replay modified and inspect the new request, events, and attempts.

Provider Signatures And Trust

If a provider signs the original body or URL, changing the replay body, path, query, or certain headers can make the original provider signature invalid. That is expected.

For receiver verification during modified replay, prefer FastHook destination delivery signatures or a receiver-side debug mode that is explicitly limited to replay testing. Do not train production receivers to trust stale provider signatures after the body has changed.

• Stripe-Signature, GitHub X-Hub-Signature-256, and similar provider signatures are normally bound to the exact original payload.
• Changing the body means the old provider signature should not verify.
• Changing path or query can break providers that include URL components in their signature base string.
• Keep modified replay behind API authentication and team scope.
• Use receiver idempotency keys even for modified replay tests.

Common Use Cases

Modified replay is useful when the destination contract changed but the original provider event is the best test fixture. It also helps verify fixes without waiting for the provider to emit another matching event.

Keep the first replay small and visible. If the test works, update the source, connection, transformation, or destination configuration so future traffic does not need manual edits.

• Change a path to test a new receiver route.
• Add a missing content-type header before resending a JSON body.
• Remove a noisy header that made a downstream proxy reject the request.
• Patch a payload field to confirm a receiver bug fix.
• Add a query flag such as dry_run=true when the receiver supports it.
• Validate a transformation result against a real historical request.

Operational Guardrails

Modified replay can be more dangerous than exact replay because it creates a request that never came from the original provider in that exact shape. The safest habit is to use it for diagnosis, then encode the fix as a connection rule, transformation, or receiver change.

Do not start with repeated modified replays against production. Prove one request, inspect the result, and only then decide whether exact bulk recovery or a transformation is the right next step.

• Confirm the destination is safe to receive the edited request.
• Use a dry-run path, test destination, or CLI tunnel when possible.
• Inspect attempts and response bodies after each modified replay.
• Avoid changing business identifiers unless the receiver is designed for that test.
• Document why the request was modified if the replay affected production state.
• Move repeatable edits into transformations instead of manual replay.

Next

• Webhook replay with modifications
• Request trace page
• Share sanitized requests
• Webhook replay systems
• Transform webhook payloads
• Deduplication patterns
• API reference