Docs

Core Concepts

FastHook is organized around a small set of concepts. Once those concepts are clear, the dashboard, API reference, and quickstart flow become much easier to reason about.

The short version: a source receives an inbound webhook request, FastHook creates an event, a connection decides where that event should go, and a destination receives the outbound delivery attempt.

Event Flow

Most FastHook workflows follow the same path. A provider or internal service sends one HTTP request to a source URL. FastHook captures that request, turns it into an event, then uses connections to deliver the event to one or more destinations.

Flow
Provider webhook
  -> Source URL
  -> Request
  -> Event
  -> Connection
  -> Destination
  -> Attempt

Core Objects

  • Source: the public ingress endpoint that receives provider or application traffic.
  • Destination: the outbound HTTP endpoint that should receive routed events.
  • Connection: the route between one source and one destination.
  • Request: the inbound HTTP call accepted by a source.
  • Event: the routable unit created from an accepted request.
  • Attempt: one outbound delivery try from FastHook to a destination.
  • Rule: optional behavior on a connection, such as retry, filter, delay, deduplication, or transformation.

Example Route

Imagine Stripe sends billing events to your product. Instead of pointing Stripe directly at your billing API, you create a FastHook source, register the source URL in Stripe, and connect that source to your billing destination.

That gives you a durable place to inspect payloads, retry failures, pause traffic, and add routing rules without changing the provider URL.

  • Stripe sends a checkout.session.completed webhook to a FastHook source.
  • FastHook stores the request and creates an event.
  • A connection routes the event to your billing API destination.
  • If the billing API is temporarily unavailable, retry rules can deliver the event again later.

Why The Split Matters

FastHook separates receiving traffic from processing traffic. That separation is what makes webhook operations safer: you can accept provider traffic even when a downstream service is slow, inspect the original request, and recover failed deliveries after the receiver is fixed.

It also keeps routing changes inside FastHook. When you add a new consumer, change a destination, or filter noisy events, the provider can keep sending to the same source URL.

When To Add Rules

Start with a plain source, destination, and connection. Add rules only when the route needs extra operational behavior.

  • Add retries when the destination can fail temporarily.
  • Add filters when only some event types should reach a destination.
  • Add transformations when the receiver needs a different payload shape.
  • Add deduplication when provider retries can repeat the same business event.
  • Add throughput controls when a destination has strict capacity or rate limits.

Next