Asynchronous APIs are everything that doesn’t fit the simple synchronous request-response model that REST made dominant. In a synchronous API you make a call and wait for the answer. In an asynchronous, event-driven API the relationship is inverted or decoupled — something happens, and you get notified; or you subscribe to a stream and receive data as it flows; or you publish a message and some other system consumes it on its own schedule. I’ve spent years arguing that async patterns are not a replacement for REST but a maturity layer on top of it, and that the governance challenge of the next decade is bringing async and event-driven APIs under the same management discipline we spent fifteen years building for HTTP.
My core position, which I’ve stated many times and most clearly in 2025, is that this is not REST versus GraphQL, or REST versus Kafka. It is REST and hypermedia and GraphQL and gRPC and event-driven, plus whatever other useful patterns emerge. Simple pragmatic HTTP stays at the center, and the graph, event, model, and streaming patterns ebb and flow at the edges depending on genuine technical need. The vendor and investor hype cycles love to frame each new pattern as displacing the last one — async kills sync, events kill REST — but that framing has always been wrong. The mature answer is a robust, diverse API toolbox, and knowing which tool fits which job. Event-driven approaches reflect where a lot of the future is, but they require time, learning, and real infrastructure investment to apply well.
Webhooks are where almost everyone enters the asynchronous world, and they’ve been part of the conversation since the very beginning. I was writing about PubSubHubbub as a pub/sub layer for APIs back in 2011, addressing the wastefulness of constant polling — why hammer an endpoint asking “anything new?” when the server could just push you the update when it happens. By 2013 I was describing webhooks as the common building block for the automation and reciprocity platforms like Zapier and IFTTT, the thing that made API integration a two-way street instead of a one-directional pull. Webhooks are the foundational event vocabulary. They establish that your platform has events worth knowing about, and they deliver those events over plain HTTP, which means they’re cheap, broadly compatible, and accessible to the widest possible audience.
That accessibility is why I keep pushing teams to exhaust the HTTP options before reaching for heavier machinery. I made this point in 2025 looking at Adyen’s use of OpenAPI webhooks: before teams go to WebSockets, Kafka, or gRPC for delivering events, they should take a fresh look at staying within the HTTP realm with webhooks. Staying in HTTP is more cost-effective and speaks to a far wider audience than the specialized streaming stacks. A lot of event-driven needs are fully met by well-designed webhooks, and reaching past them prematurely is how teams end up with expensive infrastructure that only their most sophisticated consumers can actually use.
Above webhooks sits a progression of increasingly capable, increasingly demanding patterns. Server-Sent Events are the next step — an HTML5 standard for one-way server-to-client push over a single HTTP connection. I wrote about SSE in 2017 as one of the more underappreciated tools in the landscape: making a web API real-time doesn’t always require a two-way connection. When you replace basic request-response with SSE and stream only what changes — financial tickers, news, currency updates, usage dashboards — a whole new category of efficient real-time experiences opens up, without leaving the comfort of HTTP. Above SSE you get WebSockets for genuine bidirectional real-time, and then the industrial-grade streaming and messaging infrastructure: Kafka, message brokers, and the protocol zoo of AMQP, MQTT, STOMP, XMPP, and the rest. gRPC sits in here too, bringing bidirectional streaming over HTTP/2 with integrated auth — one of the few high-performance streaming approaches that kept faith with the web rather than abandoning it.
I mapped this as a maturity model: 101-level is webhooks, 201-level adds SSE, WebSub, and formal pub/sub, and 301-level brings AMQP, Kafka, and the heavy Apache streaming projects. The providers furthest along — Twilio, SendGrid, Stripe, Slack, GitHub — didn’t start at the top. They built a solid request-response HTTP foundation with well-defined resources and known event types, then layered push technology, streaming, and query capabilities on top as their operations and their consumers matured. Investing in event-driven infrastructure was never just about adopting Kafka. It was about having a well-defined HTTP base and a suite of event-driven approaches in your toolbox, deployed deliberately.
The reason async matters so much from a governance and business standpoint is that events are where the value actually lives. I wrote in 2017 that the events occurring because there’s an API — an order placed, a record updated, a batch imported, a subscriber added — are what have real value to consumers and operators. That’s why we do APIs in the first place. The implication for monetization is significant: instead of charging purely by the number of API calls, you might charge based on subscribers to a particular event or the type of event consumed. The event is a more honest unit of value than the request, because it maps to something that actually happened in the business.
Which brings me to the governance gap, the thing I think is the real story for the years ahead. We spent 2006 to 2016 building an entire discipline of API management around synchronous HTTP APIs — portals, onboarding, accounts, applications, authentication, logging, analytics, rate limiting, monetization. Almost none of that infrastructure exists in mature form for event-driven APIs. I’ve argued that the next frontier of API investment won’t be artificial intelligence; it’ll be backfilling everything enterprises take for granted with HTTP API gateways, but for event-driven APIs. Analytics for event streams. Composition of events. Monetization of subscriptions. Authorization scoped to topics and channels. Rate limiting reconceived for a world where you’re not counting requests but managing subscriptions and throughput. The technology for event-driven APIs has run far ahead of the management and governance tooling, and closing that gap is the work.
The specification side is maturing to support this, and it’s done so in a way I find genuinely healthy. AsyncAPI emerged in 2017 as a protocol-agnostic, machine-readable way to define message-driven APIs across MQTT, AMQP, WebSockets, STOMP, and more — deliberately mirroring OpenAPI so that anyone who understood one could understand the other. The detail I love most is that the HTTP binding in AsyncAPI is just OpenAPI. Rather than reinventing, AsyncAPI reused what already existed, which is exactly what APIs are supposed to be about. Alongside it, CloudEvents standardized event metadata, WebSub carried forward the PubSubHubbub lineage, and schema registries — like the one in Amazon EventBridge — emerged as what I called the heartbeat of operations, a complete view of the digital bits flowing around the enterprise. Governing async well means treating event schemas with the same rigor, versioning, and discoverability we apply to OpenAPI contracts.
The governance throughline is this: asynchronous and event-driven patterns are not exotic alternatives to be kept in a separate silo, and they’re not a wholesale replacement for REST to be migrated to wholesale. They’re additional tools in a diverse toolbox that the organization has to govern coherently — the same authentication, the same discovery, the same lifecycle discipline, the same monetization thinking, the same machine-readable contracts, applied across synchronous and asynchronous patterns alike. The mistake is letting the event-driven side grow up ungoverned because it arrived later and looks different. The maturity isn’t in choosing async over sync. It’s in managing both under one consistent governance practice, with HTTP at the pragmatic center and the event-driven patterns deployed deliberately at the edges where they genuinely earn their cost.
References
- The Value Of API Driven Events
- Understanding Server-Sent Events (SSE) As Part Of The API Landscape
- Streaming And Event-Driven Architecture Represents Maturity In Your API Journey
- Understanding The Event-Driven API Infrastructure Opportunity That Exists Across The API Landscape
- Adyen Webhook Is Good Use Of OpenAPI Webhooks
- Backfilling Everything API Management Did For HTTP APIs But For Event-Driven
- HTTP APIs And GraphQL And Event-Driven And Model Context Protocol
