Event Destinations is a specification and an initiative — and the fact that there is any initiative at all is more significant than most people appreciate. The core of what it does is simple: it extends where an API can deliver events beyond the traditional HTTP webhook endpoint to include message queues, event buses, and other asynchronous delivery targets like AWS SQS, GCP Pub/Sub, Amazon EventBridge, RabbitMQ, and Kafka. Stripe coined the term and was first to ship a real implementation. Shopify followed with AWS EventBridge and GCP Pub/Sub support. Twilio built something similar under the name “Event Streams” with configurable “Sinks.” Hookdeck — an event gateway company — has been maintaining the specification and running the initiative since then. The GitHub repository lives at hookdeck/event-destinations, the site is eventdestinations.org, and AsyncAPI’s Fran Méndez has publicly blessed it as a meaningful step toward the asynchronous API future he’s been working toward for years. All of this is notable because it represents the API industry finally attempting to standardize the event delivery layer — something it has conspicuously failed to do for the better part of two decades.
The problem Event Destinations is solving is the problem with webhooks, which is really just the problem with how the API industry handles asynchronous patterns generally: we never standardized any of it. Webhooks have been how APIs push events to consumers since around 2007, when Jeff Lindsay coined the term and Salesforce and others started shipping them. For fifteen years they were the only real option, and in that time essentially nothing about them got standardized. There is no universal contract for what a webhook payload looks like. There is no standard for how retries should work. There is no agreed security model — HMAC signature verification became a de facto convention eventually, but it took years and the implementations vary. There is no standard for how you register a webhook endpoint, how you unregister it, how you inspect deliveries, how you replay failures. Every API that delivers webhooks built its own system from scratch and called it whatever they wanted. Stripe’s webhooks, Twilio’s webhooks, Shopify’s webhooks, GitHub’s webhooks — all deliver events to HTTP endpoints, all are conceptually identical, and none of them are compatible with each other in any meaningful way. Sagar Batchu from Speakeasy put it bluntly: “Webhooks are a great idea, suffering from a bad implementation.” This is accurate but arguably understates it. The implementation isn’t just bad — it was never attempted at a standards level. We just let every vendor ship whatever they felt like.
What the initiative identifies as the core limitations of the webhook model are worth sitting with, because they reflect a broader pattern in how the API industry has built things. Webhooks require the consumer to operate an HTTP server reachable from the public internet. That requirement alone eliminates a significant class of consumer architectures — internal services, batch processing systems, event-driven pipelines — that would be perfectly natural consumers of API events if the delivery could happen via a message queue instead of an inbound HTTP call. Webhooks have no built-in delivery guarantees. At-least-once delivery, deduplication, idempotency handling — all of that is the consumer’s problem to solve, if they solve it at all. The retry logic across different vendors is inconsistent and often underdocumented. Security is opt-in and the implementation details differ everywhere. The operational overhead of running a webhook consumer — the inbound infrastructure, the error handling, the replay tooling — is substantial and largely invisible in the vendor’s documentation. When the industry finally got around to writing an asynchronous API specification in AsyncAPI, it described event-driven systems comprehensively and correctly, but AsyncAPI doesn’t tell you how to actually configure and manage where events go in a real deployment. That gap between the spec and the implementation is exactly where Event Destinations is trying to operate.
The specification itself is deliberately lightweight and worth reading in full because its simplicity is part of the point. There are four required things: support at least two destination types including webhooks, implement automatic retries with exponential backoff, provide CRUD management APIs for destinations, and send failure alerts to developers. Then there are six recommended things: at-least-once delivery with idempotency, topic-based subscriptions, auto-disabling of persistently failing destinations, a developer UI, manual retry capability, and payload-based filtering. That’s it. The specification doesn’t try to define a universal schema for the management API. It doesn’t define a standard payload format for events across implementations. It doesn’t specify how authentication to the destination should work beyond noting the problem. The draft status is honest about where things stand — this is a conversation-starter and a rallying document, not a mature standard. What it is trying to do is establish shared vocabulary and shared expectations around the minimum viable event delivery system, so that API producers who implement these patterns are interoperable in spirit even when they can’t be interoperable technically. It’s asking the industry to agree on what good looks like before defining every detail of how to get there.
The political situation around Event Destinations is the thing I watch most carefully, because the graveyard of API standards initiatives that died from governance problems is long. The specification currently lives in a GitHub repository maintained by Hookdeck. Hookdeck is an event gateway business — they sell a product that sits between event producers and consumers and handles delivery, retries, transformations, and observability. Their commercial interest in a world where event delivery is standardized and interoperable is real and legitimate — standards create larger markets for infrastructure products that plug into them. But a standard maintained by a commercial vendor, even a well-intentioned one, has structural tension built in. Stripe coined the term and pioneered the concept. Shopify, Twilio, and others are early adopters. But the specification doesn’t yet have a vendor-neutral home — no Linux Foundation project, no CNCF working group, no OpenAPI Initiative involvement, nothing like what gave OpenAPI and AsyncAPI their longevity and credibility. It’s draft status with no published versioning scheme and no formal governance model. The contributing guidelines exist in the repository but there’s no steering committee, no release process, no defined path from draft to ratified. This is fine for a nascent initiative, and it’s the same place most standards begin. The question is whether the critical mass of producers will show up to give it the institutional weight it needs to graduate to something stable.
Where Event Destinations sits in the wider API landscape is interesting because it’s operating in the space between the REST API world and the event-driven / messaging world that AsyncAPI governs, and it’s filling a gap neither side has adequately addressed. AsyncAPI is superb at describing event-driven systems — what messages look like, what channels exist, what protocols are in play. But AsyncAPI describes the system, it doesn’t standardize the configuration and management surface for how you tell a producer where to send your events. OpenAPI covers the HTTP management API surface comprehensively, and you could use OpenAPI to describe an Event Destinations management API, but OpenAPI doesn’t say anything about what behaviors that API should exhibit or what destination types it should support. Webhooks specifications have been proposed over the years — there’s a Standard Webhooks initiative that overlaps partly with this space — and various vendors have published their own developer documentation. Event Destinations is attempting to synthesize this into a coherent minimum bar that producers can be measured against. The four required behaviors are genuinely the minimum. Any API that is delivering events to consumers and can’t auto-retry with exponential backoff, can’t let you delete a destination, and doesn’t alert you when things break is not delivering events responsibly. The recommended behaviors are the next level of seriousness. The initiative is essentially writing down what the serious implementations already do and asking the rest to catch up.
The AI agent dimension is where this becomes relevant in ways the initiative probably didn’t anticipate when it started. Agents are becoming primary API consumers, and agents need reliable event delivery even more than human-operated systems do because they have less tolerance for undefined behavior. An agent that needs to respond to events — a payment processed, a document updated, an inventory level crossed — needs those events delivered reliably, with clear semantics, to an infrastructure component it actually controls. A message queue that the agent’s runtime reads from is a much better integration point for most agent architectures than a webhook endpoint that requires the agent to be listening at a publicly accessible URL. The work Event Destinations is doing to standardize that message-queue delivery path is directly useful to the agentic API consumption layer. And the CRUD management API that the specification requires is exactly what an agent needs to configure its own event subscriptions dynamically — to say “when X happens, deliver the event to this SQS queue” without a human needing to configure it manually. This isn’t a use case the initiative has centered, but it’s one where the standardization work pays dividends immediately.
My read on Event Destinations is that it’s the right initiative at the right time, doing the right scope of work — and that the thing standing between it and lasting impact is whether it can find a vendor-neutral institutional home before it either stagnates or gets captured. The pattern I have seen too many times is an initiative like this getting to a certain level of adoption and then either losing steam because the primary maintainer shifts priorities, or getting institutionalized inside one vendor’s product roadmap in a way that slowly diverges from the original open intent. The Standard Webhooks initiative had some of this same energy and covers overlapping ground. Having two initiatives addressing webhook and event delivery standardization without a clear merger or differentiation story is a fragmentation risk the space doesn’t need. What I’d like to see is this work finding its way into AsyncAPI governance — either as a companion document or as a new section — because AsyncAPI is the closest thing the event-driven API world has to a credible multi-stakeholder standards home. Barring that, a CNCF sandbox project would give it the governance structure and community legitimacy it currently lacks. The technical work is solid. The political work of building the institution around it is what determines whether it matters in five years.
