FastHook core concepts

FastHook is an automation platform with webhook infrastructure built in. The primary user journey is to select an event, build a Workflow from steps, and inspect every run.

Automation flow

Connected account
  → Source trigger
  → Workflow run
  → Step inputs and outputs
  → Action in another app

Connected account

A connected account authorizes FastHook to listen for events or perform Actions in a provider. An account can be reused by compatible Sources and Actions. The available authentication method depends on the provider and may be OAuth, an API key, a bot token, or another provider credential.

Source and trigger

A Source is the saved FastHook resource that receives or detects events. Inside a Workflow, the selected Source is presented as the Trigger.

Provider Sources can use instant provider callbacks, polling, or a provider-specific notification channel. A generic Webhook Source receives an HTTP request at a dedicated URL.

Workflow

A Workflow is a directed graph attached to one Source. It has a version and one of four lifecycle statuses: Draft, Active, Paused, or Disabled. Only active Workflows process new Source events.

The graph must remain acyclic: a later step may depend on the Trigger or an earlier step, but a step cannot depend on itself or create a loop.

Step

A Step is one unit of workflow behavior. FastHook currently models these step kinds:

• Action calls an operation in a provider app.
• Destination sends data through a reusable delivery transport.
• JS Transformation runs a reusable transformation.
• JSON Patch changes JSON using RFC 6902 operations.
• Filter continues only when its rules match.
• Delay waits before the workflow continues.
• Paths splits execution into named conditional routes.

Action

An Action performs provider work, such as sending a message, creating a record, updating an issue, or adding a spreadsheet row. Each Action defines its own authentication modes, required fields, input schema, output schema, and rate limit.

Data mapping

A mapping connects data from the Trigger or an earlier Step to an Action field. Trigger paths begin with trigger; step outputs begin with steps.<step-id>. The builder's field picker creates these references for you.

Paths and filters

A Filter either continues on its default route or stops that branch. Paths can run one or more matching named routes in order and can include one fallback route for the no-match case.

Run and step run

A Run is one execution of a Workflow for one Source event. A run is queued, running, succeeded, or failed. Each eligible step creates a step-run record that can be pending, running, succeeded, failed, or skipped.

Workflow Audit preserves the workflow version, trigger preview, step order, inputs, outputs, response status, and error information needed to explain an execution.

Connections and Destinations

A Connection is the original direct routing model: Source → Connection → Destination. It remains separate from Workflows and is useful for direct webhook delivery, independent retry rules, replay, and transport-level routing.

Use a Workflow for multi-step app automation. Use a Connection for direct delivery infrastructure. A Workflow may also contain a Destination step when both models are useful together.

Requests, events, and attempts

These webhook infrastructure records remain visible outside the Workflow builder:

• A Request is the inbound HTTP request accepted by a Source.
• An Event is the unit routed through the delivery pipeline.
• An Attempt is one outbound delivery try to a Destination.

Use Activity and Workflow Audit for automation execution. Use Requests, Events, and Connection history for webhook transport investigation.