Building Event Streaming From the Catalog

Building Event Streaming From the Catalog

Event Streaming & Event-Driven Architecture at apis.io/use-cases/event-streaming/ resolves 50 providers and 1,101 APIs — event backbones and message brokers that carry events between producers and consumers, plus the decoupled architectures built on top: webhooks, choreography, event sourcing.

It is the largest use-case by API count on the network.

The cohort

Provider Score Band APIs
Salesforce 80.5 Exemplar 294
Convoy 73.6 Exemplar 11
Oracle GoldenGate 71.3 Exemplar 37
Amazon Kinesis 70.8 Exemplar 11
Google Forms 69.8 Strong 3
Azure Container Apps 69.1 Strong 5
Amazon Managed Apache Flink 68.1 Strong 31
Adobe Experience Cloud 67.9 Strong 36
Azure Functions 67.9 Strong 23
Choreo 67.1 Strong 16
Amazon MSK 65.7 Strong 6
AWS Lambda 65.6 Strong 12
Amazon MQ 65.5 Strong 5

A build path

The cohort splits into three layers, and choosing at the wrong layer is the usual mistake.

Transport. Amazon MSK (65.7) for managed Kafka when you need a durable, replayable log and your team already thinks in topics. Amazon Kinesis (70.8) when you want the same shape with less operational surface. Amazon MQ (65.5) when you are carrying an existing JMS or AMQP application and need a broker rather than a log.

Processing. Amazon Managed Apache Flink (68.1) for genuine stream processing — windowing, joins across streams, stateful aggregation. AWS Lambda (65.6) and Azure Functions (67.9) for the far more common case where each event is handled independently and you just need code to run.

Delivery. Convoy (73.6) is the specialist worth knowing about — 11 APIs, exemplar band, and it does one thing: reliable webhook delivery with retries, signing, and a dead-letter path. Most teams build that badly in-house three times before buying it.

Change data capture. Oracle GoldenGate (71.3) when the events you need are database mutations rather than application-emitted messages.

The Salesforce entry

Salesforce at 80.5 across 294 APIs is the highest composite in this cohort and slightly misleading as a “streaming” provider. It appears here because of Platform Events and Change Data Capture — a CRM emitting a genuine event stream. If your events originate in Salesforce, that stream is the source of truth and you should consume it directly rather than polling.

The description gap, again

This week’s AsyncAPI piece found 1,768 definitions across just 661 providers on a catalog of more than 25,000. That gap is felt precisely here. The 50 providers in this use-case are the ones who build event infrastructure — they describe events well because events are their product.

Everyone else sends webhooks and documents them in prose. The infrastructure is excellent; the description of what flows through it is where the catalog thins out.

Takeaway

50 providers, 1,101 APIs, and a clean three-layer split between transport, processing, and delivery. Pick the layer before the vendor — and if all you actually need is reliable webhook delivery, Convoy at 73.6 will save you from building it yourself.

Browse the use-case at apis.io/use-cases/event-streaming/.

← Aerospace on APIs.io
Profiling Merge: 118 APIs of Unified Integration →