Creating API mashups has matured alongside the explosive growth of open APIs to create a new type of service: the API aggregation business. These innovative businesses combine APIs from multiple providers to build new products and services. Recent conference panels (including several hosted by ProgrammableWeb), have confirmed that API aggregation is set to be a major theme of 2014. This article explores some of the emerging business models and service providers focused on API aggregation and discusses what to expect as we see API aggregation increase in the year ahead.
Over the past several months, at least 5 of the API aggregation businesses listed below have overhauled their user interfaces in order to impove the end user experience. This focus on end user interfaces suggests a growing recognition of the demand for aggregation services and the value in providing an uncluttered user experience that reduces complexity.
After all, API aggregators are focused on the business value of trying to help end users reduce the complexity that comes with API integration. Whether it be to avoid end users needing to learn code, help end users streamline workflows, or help move directly into analytics and engagement processes (allowing the aggregators to do the collation and data display work), the central tenet is that value is created by simplifying the complexity that comes from working with the multiple datasets that sit behind the APIs.
For many businesses in the API aggregation space, developing viable business models will remain a key challenge. As Bryan Helmig from Zapier commented at API Strategy and Practice in October, aggregation business customers are “all longtail”. Aggregation aims to make use of the ever-growing landscape of APIs available, themselves built because of the multitude of data needs and specific business services required for integration. End users of API aggregation often have highly specific workflow or data collation needs that are too complex to choreograph without provider support.
There is also a breadth of diversity in how results are provided from API aggregation businesses. Some have a one-to-one type relationship: they pull data from one API source and push it to another. Some have a many-to-one model that pulls services and data from multiple API sources and delivers it in the one output, a visualization, for example. Recently, a newer aggregation service has been emerging offering many-to-one solutions that draw service and data from multiple APIs and then repackage it into one API for end users to access.
Examples: Zapier, Itduzzit, Temboo, RunMyProcess.
API Workflow: Pull API data from one source and push it to another.
Monetization: Predominantly subscription-based with pricing levels set by number of integrations and/or number of API calls made each month.
These API aggregators tend to have a library of SaaS and (increasingly) IoT services that can be integrated with any other service to create an automated workflow. Behind the scenes, the business is using the external service’s APIs to create integrations that allow non-programmer customers to easily integrate APIs into a seamless workflow. Zapier is one of the largest providers in this space and has just finished an overhaul of their user interface. Temboo takes a slightly different tack: their service helps programmers connect several APIs into an automated workflow and then creates the code snippets that a consumer-developer can paste into their application. Fujitsu RunMyProcess uses API sources to create and automate extensive workflows across the entire process, not just for individual tasks.
Examples: Creative agencies (like Deportivo), Digital PR firms.
API Workflow: Pull API data from multiple sources, combine it and then push it to output… and then loop back around based on further engagement/feedback.
Swedish creative agency Deportivo (to be featured in a ProgrammableWeb interview next week) uses APIs as part of their “creative pallet” to design digital campaigns for their brand clients. In their case, they have aggregated APIs from a variety of sources to create engaging campaigns on social media or in public spaces to interact with target audiences. Creative agencies and digital PR companies are a growing sector of API consumers, not just using APIs to monitor marketing analytics or social media (see types 4 and 5 below), but as part of the PR campaign itself. We have seen this recently on ProgrammableWeb with brands like Nike using the Stupeflix API, while performance monitoring service Load Impact told us that one of their largest markets is creative agencies who are stitching together interactive campaign content using APIs.
These aggregation services pull content based on relevant keywords (or hashtags) and display it in a curated format. They use APIs to collect the data from external media sources and then package up the results, often updating realtime feeds regularly (dependent on refreshing API calls, usually around 10 minutes or so). Among some services, advanced subscription plans can provide the results back to end customers in API format. Tagboard is another example of an aggregation service that has recently overhauled its user interface to attract more customers.
Like with automation aggregators, dashboard services like Ducksboard provide a library of the services they can draw from (behind the scenes, accessing the relevant API), alongside privately-held data to create analytics and business intelligence dashboards for end users. Again, Ducksboard has overhauled their user interface, as recently reported on ProgrammableWeb. This is a well-established space with multiple players vying for market share in a profitable, and growing, sector. New entrants like sush.io are focusing on doing one thing well, in their case, marketing analytics dashboards based on drawing on API feeds from marketing SaaS providers, while Good Data offers a service targeting enterprise customers. (In addition to feeding multiple APIs into a dashboard interface, Adigami also fits into type 7 below as they also bundle the aggregated APIs to push back out in a single API.)
API Workflow: Pulls data from multiple APIs to push to a visual output (dashboard).
Monetization: Private billing.
These services are a cross between types 2, 3 and 4. The idea is along the lines of how creative agencies are using APIs, but more focused on fostering audience engagement perhaps in response to a PR campaign, rather than woven into the campaign delivery. These aggregators may use APIs to draw in specific account social media feeds and business intelligence sources alongside broader content feeds in order to identify opportunities for audience engagement. Like other players seeking to consolidate their market potential, Postano has recently updated its user interface but its’ website pricing pages remain coy about the business model, offering to demo the product to interested leads. These services may have some difficulty truly scaling as there may be some tweaking involved dependent on individual customer or campaign needs, hence the private billing approach.
API Workflow: Pulls data from multiple APIs, analyzes and applies algorithms and pushes results to a visual output (including widgets and APIs).
Monetization: Affiliate commissions off recommended results.
These services use APIs that access open and proprietary data sources alongside either personalization APIs or user input to perform calculations and return a priority list of suggested results (they may even use APIs to identify affiliate links to add in the response data provided). These aggregation services are reminiscent of the sort of workflows many developers originally had in mind when thinking about mashups created using API data, now taken to the next level with more sophisticated business models and the opportunity to combine with algorithms like those offered by SwiftIQ and other services.
These are part of an exciting new approach to API aggregators. They draw on multiple APIs and create a single API through which to access all the underlying data sources. Zypr’s model is particularly interesting. They offer developer-consumers a revenue-sharing model based on the search ad results that are displayed in-app as part of the API returns (for example, if creating a travel app that draws on multiple API sources and is used via the single funnel Zyper API). Other models, like Segment.io are a spin on the BI/analytics aggregate model (type 4 above), but focused on funneling access to a variety of API sources via a single API that end users can incorporate into their own reporting mechanisms and preferred dashboards.
Examples: Yodlee, Stormpulse.
API Workflow: Pull data from multiple (mostly open data) API sources and combine with APIs pulling from designated private accounts, analyze and combine data and push results into output (dashboards and apps).
Monetization: Private contracting, subscription, partnership models.
Again, these models emulate or extend the principal ideas behind mashups by remixing open data with proprietary sources, algorithms, and then adding the end users private data via API to create personal intelligence reports. These may be in the form of apps, alerts or dashboards that help end customers take action as relevant. Yodlee Interactive is the best example of this model, working with partner developers to identify individual business models and revenue share strategies based on the intended end user target audience or potential for scaling the app product, etc. A quick look at Stormpulse appears that they use a similar aggregation model, both for a SaaS delivered subscription service, and higher-end contract work with agriculture clients. In their case, they are remixing open weather data with their clients proprietary data and perhaps other location specific data routed via API to calculate weather hazard risks to support local agricultural decision-making.
At recent conferences where ProgrammableWeb has moderated panels, we have heard multiple discussions around how to aggregate APIs for either internal business use or to create new customer-facing products and services. This is being driven by the ever-increasing availability of APIs, and the strengthening skill-set amongst developers within businesses who are taking on a technical business analyst role and contributing to defining and implementing business workflow processes across the organization. For forward-thinking businesses that are taking a “composable enterprise” approach in which services and internal departments are being reorganized into discrete API-enabled departments, this is sparking a cultural mindset that leads businesses to think about how they can aggregate internal services with external sources via API to generate new business intelligence, create new products, and enter new markets.
This is an initial look at documenting API aggregation services and feedback is welcomed to help clarify models and monetization strategies being applied by some of the key players and first movers.