Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What Hookdeck is
Hookdeck describes itself as providing reliable infrastructure to work with webhooks and external events without managing it yourself. The inbound product is the Event Gateway, which manages inbound webhooks and events before they reach your application, including receiving, transforming, and routing, with full observability.
Architecturally it is a proxy and a queue: Hookdeck acts as an HTTP proxy and queue between the webhook producer and your application.
The model is layered: an inbound HTTP call becomes a request; a request matched to a connection becomes an event; each delivery of that event is an attempt.
What it is normally used for
How Hookdeck is used generally, before Synedrix OS enters the picture.
- Buffering: if a destination is unreachable, events are held in the queue and delivered when the server recovers
- Retries: automatic linear or exponential retry strategies against a failing downstream
- Replay: bookmarks re-issue past traffic against a corrected consumer
- Filtering and fan-out: one source routed to many connections, each with its own rules
- Signature verification: HMAC and provider-specific verification before anything is trusted
What it owns, and what it does not
Every platform in the stack has a non-overlapping responsibility. The boundary is as much a part of the design as the capability.
Owns
- Inbound event validation
- Schema enforcement
- Buffering
- Replay
- Fan-out
Does not own
- Outbound and callback delivery
- → Hookdeck Outpost (Layer 8, egress)
- The event envelope, naming and lifecycle rules
- → Event Taxonomy Standard
- Workflow sequencing and approval routing
- → n8n (Layer 3)
- Whether an event may cause a side effect
- → Policy Guard (os-agt-002, Layer 9)
- Lineage graph and audit trail
- → Neo4j (Layer 7) and Layer 10
Why Hookdeck
A restart never means lost data
External systems send webhooks whether or not n8n happens to be running. Hookdeck holds those incoming events in a queue at the edge, so if orchestration restarts, it's a delay; nothing is lost.
Past events can be re-sent on demand
Sometimes a workflow needs to be re-run against an event that already arrived, for example after fixing a bug. Hookdeck's bookmarks make that a simple action instead of reconstructing the original event by hand.
Verification happens before the OS trusts anything
Hookdeck checks each webhook's signature right where it arrives. That means the orchestration layer only ever sees requests already confirmed to come from who they claim to.
Routing rules live in version control, not code
Connections, filters, and transformations are configured through Hookdeck's API and a Terraform provider, so they can be written down, reviewed, and tracked in version control, the same way the specifications describing them are.
Licence position
Hookdeck questions, answered
Short, citable answers drawn from this page.
What role does Hookdeck play in Synedrix OS?
Hookdeck (Ingress gateway) is mapped to Layer 8: Event in Synedrix OS. The queue at the edge. Events arrive whether or not the orchestration layer is up.
What does Hookdeck own in Synedrix OS?
Hookdeck owns: Inbound event validation; Schema enforcement; Buffering; Replay; Fan-out.
What does Hookdeck not own in Synedrix OS?
Hookdeck does not own: Outbound and callback delivery (owned by Hookdeck Outpost (Layer 8, egress)); The event envelope, naming and lifecycle rules (owned by Event Taxonomy Standard); Workflow sequencing and approval routing (owned by n8n (Layer 3)); Whether an event may cause a side effect (owned by Policy Guard (os-agt-002, Layer 9)); Lineage graph and audit trail (owned by Neo4j (Layer 7) and Layer 10).
What licence is Hookdeck under?
Hookdeck is released under Proprietary, managed cloud service. The Event Gateway is closed-source SaaS with no documented self-hosted, on-prem, or private-cloud deployment. All of Hookdeck's self-hosting documentation covers Outpost, a separate product. Synedrix OS accepts it as the one recorded exception to Principle 11 (ADR-OS-013): it is required in every mode, and in an air-gapped deployment it is the single inbound path, holding inbound payloads in transit before delivery. Environments that forbid any third-party transit of inbound data are not a fit for air-gapped Synedrix OS today.
The full reference page, with the operating model, deployment detail, and links to every canonical specification this platform touches, lives in the documentation repository, which is private while the platform is being built.