Is Providing an External Streaming API Enough?

Is providing an external streaming API enough of an application for most API providers? Each API we add to the Streamdata.io API Gallery, we create an account, add an application, and obtain keys that allow us to make API calls. We essentially become a consumer of each API we profile and add to the gallery. However, our goal isn't to integrate a specific application or system with each API, we want to empower other application and system developers to do that. We've long seen our streaming service as something that each API provider should deliver on top of their API, but we are increasingly seeing that maybe it is an application that other API consumers can also put to work without the API provider always being an active part of the conversation.

The question is, is providing an external streaming API enough of an application to satisfy the terms of service for each API provider? Is augmenting an existing API with streaming, and event-driven capabilities seen as enough of an enhancement that API providers will support what we deliver? Or will they feel we are in violation of their terms of service and think its something they should be delivering on their own? It is a line we take seriously, and we'd prefer that API providers use our SaaS, or our on-premise to deliver our services to their customers. However, if we can't get their attention, we feel it will be valid to act like we are just another application in their ecosystem, bringing value to the community.

It is tough to understand exactly what is an API, what is an API service provider, and what is an application in this increasingly complex landscape. The line between API, provider, and consumer is blurred. We are in the business of making sure people discover and deliver the data they need to operate their businesses, organizations, and government agencies. It is important to us that the provenance of where data comes from is clear, and the terms of service of each platform are properly respected along the way. As we work to get the attention of each API provider and build relationships with them, we want to make sure we have the right understanding of where we belong in the food chain, and properly present ourselves to the APIs we are targeting.

We feel like adding a streaming API, and event-driven architecture on top of an existing is a valid enough application. We just want to make sure we aren't offending any of the APIs we proxy, and we end up on the positive side of every API provider we encounter. This is a conversation we'll keep having with the API providers we are profiling. When possible we'll reach out to each provider, as well as signing up for an account, application, and obtain a set of API keys. We see this journey as a partnership, and not something where we just take and do not give back to the API providers we depend on. Eventually, every API in the Streamdata.io Gallery will be a partner who knows about what Streamdata.io does and realizing we can help them better understand the event-driven landscape that is unfolding around us.