How AWS EventBridge API Destinations Are A Flow Innovation

The new API destinations feature of AWS EventBridge introduces a simple mechanism for defining how events processed by EventBridge should be packaged and sent to third party web APIs using standard HTTP verbs, such as GET, POST, and others. (Most commercial APIs are REST APIs, which use these verbs.) By defining some basic connection, authentication, and data formatting information using straight forward wizards and templating mechanisms, EventBridge can automatically create the right HTTP calls every time it processes a relevant event.

I highly recommend reading this blog post from AWS's James Beswick to get a better understanding of how this all works.

Why is this important news? Because AWS has just made nearly the entire API economy a valid set of consumers for your event streams without requiring you to write any code.

Do you want Twiilio to consume a customer's exceptions stream so that it can text them the information in a timely manner? Just create an API destination in EventBridge and some rules to drive the right events to that destination.

Prefer to have customer purchases be automatically tracked in your Salesforce CRM system? Once again, API destinations to the rescue.

By the way, many common SaaS environments already have supported integrations for EventBridge, so you may have to do even less work for those.

As I make clear in Flow Architectures: The Future of Streaming and Event-Driven Integration, flow without interaction is just moving data around the network. It doesn't generate any real value. However, by turning APIs into simple, "codeless" ways to interact with your event streams, AWS is opening the door to a huge ecosystem of functionality and services. AWS has basically coopted the entire HTTP API ecosystem into its event-driven applications story. It's a brilliant move.

I expect this is not lost on the other major cloud providers, nor on the rest of the EDA vendor market. I therefore also expect to see much more simplification of API consumption in event-streaming services in the years to come.

Of course, once all of these services directly consume event streams through standard interfaces and protocols, we won't need any of this. But for now, this is a great move by AWS.