Guide

Why 200 OK Does Not Guarantee Processing

A provider dashboard can show 200 OK while your business workflow still failed. In FastHook, that 200 OK is still meaningful: it means the source accepted the request and FastHook has stored the request evidence so it will not disappear.

The important distinction is receipt versus processing. FastHook returning 2xx proves durable ingress capture; it does not prove that every connection branch delivered, that every receiver processed the payload, or that the business side effect completed.

Use this guide to explain the guarantee clearly, then follow Requests, Events, and Attempts to prove what happened after the provider acknowledgement.

FastHook 200 OK Guarantee

When the 200 or custom 2xx response comes from a FastHook source URL, FastHook has already accepted the inbound webhook and persisted a request record. That accepted req_* is recoverable evidence for inspection, replay, metrics, and downstream routing.

This is the contract to underline for users and customers: if FastHook returned 2xx for the source request, the accepted request is not lost. What remains uncertain is the work after acceptance.

  • FastHook reached the source gate and accepted the request.
  • The request record exists as req_* with headers, body, method, path, source_id, and status accepted.
  • The accepted request can be inspected and used for replay or recovery.
  • The provider may stop retrying that delivery.
  • Downstream branch events, delivery attempts, and business side effects are separate evidence.
FastHook 2xx is a durable ingress acknowledgement, not a destination processing receipt.
FastHook source acknowledgement
Provider POST
  -> FastHook source URL
  -> source method/auth check
  -> req_* stored with status accepted
  -> FastHook returns 200 or configured custom_response

What 200 OK Does Not Prove

The 200 response is intentionally early. It prevents provider retries after FastHook has the request, but it should not be used as the final proof of downstream processing.

  • Every connection filter matched.
  • Every connection branch created an event.
  • Every destination received a successful attempt.
  • The receiver accepted the FastHook delivery signature.
  • The receiver's internal queue accepted the job.
  • The business side effect completed.
  • Duplicate deliveries are safe in your application.

Follow Request, Event, Attempt

After a provider sees 200, debug from stored evidence outward. Start with the Request to confirm ingress. Then inspect Events to see which connection branches were created, ignored, held, queued, delivered, or failed. Finally inspect Attempts to see the exact receiver response.

A provider resend is usually not the first fix after FastHook has returned 2xx. Use event retry when one destination branch failed. Use request replay when the accepted request should be re-run through current routing.

The request is safe after 2xx. Processing proof lives further down the evidence ladder.
Post-200 inspection
curl "https://api.fasthook.io/v1/requests/req_xxx?include=data" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_xxx"

curl "https://api.fasthook.io/v1/requests/req_xxx/events" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_xxx"

curl "https://api.fasthook.io/v1/attempts?event_id=evt_xxx&order_by=created_at&dir=desc" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_xxx"

What Can Still Fail After 200

After the request is safely captured, each destination branch can still have a different outcome. This is why a provider 200 and a user-visible failure are not contradictory.

  • No active connection: the request exists, but no destination branch is created.
  • Filter mismatch: the branch can be ignored by connection rules.
  • Paused connection: the event can stay HOLD until the route is resumed.
  • Rate limit or delay: the event can be scheduled or queued before an attempt.
  • Destination failure: the attempt can fail with 4xx, 5xx, timeout, network, or signature rejection.
  • Receiver success but app failure: the downstream app can accept HTTP delivery and still fail later internally.
FastHook has the request. The operator still needs to inspect branch outcomes.

Safer Receiver Pattern

FastHook follows the reliable receiver pattern for source ingress: accept only after the request is captured, then process asynchronously with evidence. Your own downstream receivers should follow the same pattern before returning 2xx to FastHook.

For custom destinations, return success only after the receiver has completed its own minimal durable step. If it cannot store the job, return an error and let FastHook retry according to the connection rules.

Destination receiver pattern
1. Receive FastHook delivery
2. Verify x-fasthook-signature when enabled
3. Store raw payload or enqueue job durably
4. Record x-fasthook-event-id for idempotency
5. Return 2xx to FastHook
6. Process business side effects asynchronously

Operator Rule

When the provider shows 200 and the customer says nothing happened, do not start by asking the provider to send the webhook again. First prove whether FastHook accepted the request, which branches were produced, and which attempt or receiver stage failed.

  • If req_* exists with accepted status, the inbound webhook did not disappear.
  • If no event exists, inspect connection state, filters, and disabled resources.
  • If an event is HOLD, resume the paused connection when the receiver is ready.
  • If an attempt failed, fix the receiver or destination config before retrying.
  • If the attempt succeeded but the app did not process, debug the receiver's internal queue and idempotency records.
  • Use request replay only when current routing should create or recreate branch work from the stored request.

Next