Hookdeck basics

Hookdeck is an Event Gateway. A platform giving engineering teams infrastructure and developer tooling to build, deploy, operate, and monitor event-driven applications.


This section covers the fundamental concepts you should understand within Hookdeck.


Connections in Hookdeck route events from a source to a destination, optionally including additional logic through connection rules. Connections can reuse sources and destinations, allowing one event to be routed to multiple destinations.

For more information, see connections.


A source represents any service that makes an HTTP request to the URL for a source defined within Hookdeck. The HTTP requests can be inbound events such as webhooks or effectively API calls to trigger a workflow defined by a connection. Hookdeck is designed to be compatible with various content types and API providers, and supports a variety of authentication mechanisms (see authentication). Some providers require a handshake or challenge for validation, and Hookdeck supports this for several platforms.

For more information, see sources.


Represents the destination for an event to be routed to. A destination can be connected to one or many Sources.

For more information, see destinations.

Event lifecycle

The following represent different stages of the lifecycle of an event within Hookdeck:

  • Requests: An HTTP request received by a Source URL defined within Hookdeck, such as a webhook.
  • Events: An outbound event payload that Hookdeck has queued for delivery.
  • Attempts: An HTTP delivery attempt to the URL defined by a Destination.

Note that transformations are executed before filters within the event lifecycle.

For more information, see events and attempts.


Hookdeck features at a glance:

  • Bookmarks: Store and replay common and edge case requests.
  • Transformations: Transformations modify the data payload of events in transit, allowing seamless service connections by changing the data structure of the source to match the expected structure of the destination.
  • Filters: Filters define rules for processing events based on payload structure and content, headers, paths, and rejecting the rest.
  • Rate limiting: Define a maximum rate at which Hookdeck will make requests to a destination
  • Retries: A repetition of a previously attempted delivery. Retries can be triggered manually on any event, or automatically on failed events based on defined configuration.
  • Issues & Notifications: Get notified of event delivery issues, track problems in your project and communicate resolution steps with your team.

Use cases

Common use cases for the Hookdeck Event Gateway are as follows:

Inbound webhook infrastructure

Use Hookdeck as infrastructure to receive, process, and deliver webhooks to your services.

For this use case, Hookdeck takes the load off of your infrastructure by ingesting webhooks at any scale, processing them with features such as transformations to change payloads, and filtering to route or exclude events. Hookdeck also manages the delivery of webhooks to one to more destinations with a rate limit and automatic retry configuration that you define.

Inbound webhook infrastructure

Try the receive webhooks quickstart to get started.

Outbound webhook infrastructure

Reliably deliver webhook events to user and customer endpoints.

Set up connections that define the route to your customer's endpoint, making use of filters for fine-grained routing, along with rate limiting and automatic retries for an improved webhook ingestion experience for your customers. Additionally, use issues and notifications to keep track of problems with customer endpoints.

Outbound webhook infrastructure

Try the send webhooks quickstart to get started.

Third-party to third-party message routing

Connect APIs and other third-party services with the Hookdeck Event Gateway.

Use transformations to adjust event payload structure and HTTP headers, and filters to route messages between services. Use rate limiting to adhere to any third-party API rate limiting requirements and configure automatic retries to ensure that messages are successfully delivered. Additionally, issues and notifications can help you keep track of any problems with the APIs and services that you're using within your event-driven applications.

Third-party to third-party message routing

Try the third-party message routing quickstart to get started.

Asynchronous API Gateway infrastructure

Reliably consume asynchronous API requests at scale using Hookdeck as your Asynchronous API gateway infrastructure.

Use Hookdeck to authenticate and queue API requests to your infrastructure using rate limiting to throttle inbound requests. Pause API requests during planned or unexpected downtime, safe in the knowledge that API requests are queued to be delivered later and bulk retry events as part of your error recovery strategy.

Asynchronous API Gateway infrastructure

Try the asynchronous API quickstart to get started.

Serverless message broker

Hookdeck is your serverless infrastructure for asynchronous messaging between your serverless applications and services.

Define connections between the components in your event-driven architecture and use features such as filters to intelligently route messages, and transformations to conform payloads. Hookdeck reliably queues and delivers events to and between your serverless functions thanks to rate limiting and automatic retries.

Serverless message broker


Can Hookdeck return the response from a destination to the source?

Hookdeck is a platform for asynchronous messaging and therefore returns a basic customizable synchronous HTTP response to the client that has invoked the source URL. It is not possible to synchronously return a response from a destination to the client (for example, the result of an API call).

However, there are two options for your to receive the response from the destination event delivery using an asynchronous workflow:

  1. Configure an event.successful webhook notification which will contain the payload of the response from a successful request to a destination URL. See configuration webhook notifications.
  2. Send the result of any work done by a destination via a webhook callback. See the send a webhook quickstart for an example.