Event Destinations: A Better Way to Deliver Webhooks

In synchronous API development, the dominant style is REST, in which a client requests a resource from a server and gets a response. However, software architectures are becoming increasingly event-driven, relying on external events to push changes to the client asynchronously.

Events eliminate the need to constantly poll a server for changes, making them ideal for real-time updates like stock tickers, airline flight updates, weather alerts, and more, or for triggering workflows based on platform events from providers such as Stripe, GitHub, Shopify, and Twilio.

For years, webhooks have been the reigning event-driven format for API platforms to deliver such events to other platforms, integrations, or applications. Webhooks are ubiquitous — 85% of the top 100 API companies have implemented webhooks, according to The 2024 State of Webhooks Report by Svix.

The thing is, webhooks were never really standardized. Although efforts have been made, different flavors of ad-hoc webhooks are still out there, using differing payload types and authentication methods. This has led to performance inconsistencies and differing security practices across implementations.

According to Phil Leggetter, Head of Developer Relations at Hookdeck, a lack of universal approaches to event delivery has both event producers and consumers falling short. Most of the time, API providers just outsource a lot of the legwork around events to consumers, leading to inefficiencies and poor developer experiences. Some event producers do build logic to help, like automated and manual retries, debugging and observability tools, and offering different event destination types, but adoption is piecemeal and highly opinionated across providers.

Enter the Event Destinations Initiative, a community initiative spearheaded by Hookdeck. It’s described as “a model for event interoperability between event producers and their consumers.” Rather than a formal specification, Event Destinations is more of a proposed set of guidelines for event producers to follow.

Below, we’ll explore the status quo for event delivery and dive into the Event Destinations Initiative. We’ll cover some of the benefits of this approach, how to implement it, and see who’s using it in practice.

The Status Quo For Event Delivery

When developing with webhooks, the status quo is typically that an application ingests an event and attempts to run logic before the inbound webhook HTTP request times out. “This is obviously brittle and depends on the API provider having a reasonable timeout,” says Leggetter.

The recommended best practice is to use a combination of services to validate, store, and process webhooks to improve reliability and observability. Components may include load balancers, HTTP ingest workers, message queues, or blob storage mechanisms.

With webhooks, areas like security and performance optimization are optional, and the responsibility is essentially pushed to the client to figure out. Reliability is also a concern — public HTTP webhook endpoints tend to suffer from higher failure rates and incur many retried deliveries, says Hookdeck’s Leggetter. Problems with delivery typically stem from the HTTP endpoint events are being delivered to, rather than the gateways themselves, he adds.

For event producers, being locked into supporting basic HTTP endpoints for webhooks comes at a cost. “On the producer side, you end up having to build infrastructure for the lowest common denominator: under-provisioned web server resources that ingest events,” says Leggetter.

The diagram below shows the complexity of setting up a reliable event ingestion infrastructure. This is essentially what API providers are asking event consumers to implement to reliably ingest webhooks.

How Event Destinations Change Things

Instead of publishing events to HTTP endpoints and relying on the developer consumer to route them through a message bus, Event Destinations shifts the model by offering various subscription points for an event. As the Event Destination site brings into question:

“Why depend on inefficient public HTTP endpoints? Why not send events directly to secure and efficient event destinations?”

These event destinations include popular event subscription platforms, like Amazon EventBridge, Kafka, Google Cloud Pub/Sub, AWS SQS (Simple Queue Service), Hookdeck Event Gateway, RabbitMQ, and others. While not all event destinations use HTTP or ingest webhooks, they generally provide a better developer experience and better reliability around events.

Implementing Event Destinations

Event Destinations aims to make API platform event delivery and management more reliable and predictable for event producers and consumers. To meet the criteria, there are four bare minimum requirements for Event Destinations, as proposed by the Initiative:

• At least two event destination types, including webhooks
• Automatic delivery retries with exponential backoff
• APIs to create, update, and delete destinations
• Alerts for destination failures

The site also recommends some best practices, like delivery guarantees, having subscription topics, what to do after too many retries, filtering, and developer experience expectations. Hookdeck also supports Outpost, an open-source reference implementation of Event Destinations.

Event Destinations is not just theoretical — it was inspired by real-world use. For instance, Stripe’s Event Destinations allow an API consumer to receive updates from Stripe across multiple destination types, such as Amazon EventBridge and webhook endpoints. Similarly, Shopify supports various event destinations, and Twilio supports multiple event delivery sources via its sink resource.

The Benefits (For Event Producers and Consumers)

Event Destinations results in a handful of benefits for event producers. Having better standards and expectations around events could result in fewer failures and retries, resulting in reduced operational overhead. It also advocates for protocol flexibility and an improved developer experience. “Event Destinations is inclusive of webhooks, but it’s about encouraging alternatives that may be better in certain scenarios at scale,” says Leggetter.

“We need a layer between the application logic and the user to build a reliable architecture,” says Leggetter. By offering more event destinations, event producers can offload some of the burden with more direct access to their customers’ infrastructure. “It’s reducing a burden on developers (the API providers) to manage so much outbound HTTP traffic.”

From the consumer side, efficiency and developer experience are improved because you just use the queuing solution you already have in place, he says, instead of adding infrastructure to manage HTTP ingestion for events. These advantages compound when you consider the various one-off third-party webhooks integrations within your typical application.

Adding Value For Event Delivery

Webhooks are still hard to manage at scale, and with billions of non-standardized deliveries each month, ‘the ship’s already sailed,’ says Leggetter.

Instead of forcing a new universal standard, Event Destinations is more about acknowledging the divergence of event types and event platforms that have emerged over the last decade, and re-imagining event delivery with developer experience in mind. As Leggetter says:

“Instead of encouraging a different way, this is about adding value.”