API aggregators are services that bring multiple provider APIs together behind a single interface — and, in the best cases, expose entirely new APIs that only become possible because of the aggregation. I defined them this way as early as 2013, and the definition has held up: aggregation is about unifying many endpoints into one, and then about the new value that emerges when you can see and operate across all of them at once. The aggregator is the response to a problem the API economy created for itself. We spent the first decade of the web API era convincing everyone to publish APIs, and then discovered we had a new problem — too many of them, with no coherent way to use them together.
The shift was already visible to me in 2012. We were transitioning, as I put it, from “there aren’t enough APIs” to “how do we more intelligently use many APIs.” That second question is the entire reason aggregators exist. I predicted at the time that aggregators would emerge from the top industries — government, healthcare, education, finance — and that 2013 would be the year we learned to communicate more fluently with web APIs with their help. The prediction was directionally right, though the timeline, as always, ran slower than the enthusiasm.
The early aggregators I tracked each attacked a specific vertical. Adigami aggregated analytics APIs — Google Analytics, AdWords, Facebook Ads, MailChimp — into a single interface, so you didn’t have to integrate each marketing data source independently. Spreedly aggregated payment gateways, and I praised them specifically for sharing benchmarking data across the gateways they integrated. Singly worked on personal data aggregation. Yodlee aggregated financial accounts, giving developers secure access to users’ bank, credit card, investment, and loan data. Each of these was solving the same structural problem in a different domain: a developer who needed to work across many providers in a category didn’t want to build and maintain N separate integrations.
One of the most interesting things about aggregators, and something I came back to repeatedly, was that aggregation generated industry-level data as a byproduct. An aggregator that integrates dozens of payment APIs sees how all of those APIs actually perform — uptime, latency, error rates, real-world reliability. I wrote in 2013 that there was huge opportunity for aggregators to share what they learned about the common APIs they integrated. The whole industry could learn from it, and the insight could flow back upstream to the API providers themselves, giving them benchmarks of where they stood against competitors. The aggregator sits in a privileged observational position. What it sees across providers is often more valuable than any single integration it offers.
The government version of this was Fed{API}, which I covered in 2013 with a mix of enthusiasm and realism. I was — and remain — a big fan of API aggregation as the future of standardizing APIs and data across many sources. But watching providers actually attempt it made the scale of the undertaking clear. Fed{API} was trying to aggregate federal government data, which is a massive challenge on its own, while also solving the general aggregation problem — two enormous problems bundled into one business model. That combination is why public-sector aggregation has been so much harder to pull off than the optimism suggested.
By 2016 I had refined a taxonomy that separated three concepts that were often conflated: aggregation, reciprocity, and orchestration. Aggregation is bringing multiple APIs together into a single interface. Reciprocity is moving data and functionality between two API-driven services — the IFTTT and Zapier model, where the value is in the connection rather than the unification. Orchestration is the bigger picture: automation, scheduling, events, jobs, logging, the coordination of many services over time. These overlap, and some platforms operated across all three, but keeping them distinct mattered for understanding what any given middleware service actually did. Zapier had an API, but it focused on creating channels and enabling recipe development — reciprocity. That was a different thing from genuine aggregation.
Cloud Elements was my exemplar for what aggregation could be when done with real organizational intent. What I liked about them, compared to a pure reciprocity play like Zapier, was that they brought organization to the aggregation — helping you establish a stack of the APIs your business depended on and organize them coherently, all via an API. Then they added their Element Mapper, which let you map new elements programmatically, which in my framing pushed them from aggregation toward reciprocity — you could in theory build a specialized Zapier on top of Cloud Elements. They were operating across all three layers of the taxonomy at once, which is why they were interesting.
Financial data is where aggregation became most consequential and most contested. Yodlee was the leading financial aggregator, and I described their API as one of the most critical in the entire API economy — secure programmatic access to people’s bank, credit card, investment, and loan accounts. But the underlying reality was ugly: most financial aggregation ran on screen scraping, because banks wouldn’t expose proper APIs. The aggregators were logging into banking websites with users’ credentials and parsing the HTML, because the banks gave them no better option. This was fragile, insecure, and dangerous, and it persisted for years because banks were resistant to change.
The CFPB’s consumer-authorized data sharing principles in 2017 were the moment the regulatory framework for financial aggregation started to formalize. The principles outlined what good aggregation should look like: OAuth-based access instead of credential scraping, data scope limited to what’s necessary, informed consent with easy revocation, payment authorization separated from data access, strong security, transparency about who accesses your data, accuracy, the ability to dispute unauthorized access, and effective accountability mechanisms. I wrote that in a perfect world every bank would run a public API portal where fintech aggregators could register for keys and obtain user authorization via OAuth in a secure, accountable way. But we didn’t live in a perfect world, banks were resistant, and so the scraping continued. My recommendation was that a savvy bank should get ahead of it — become the AWS of banking, set the standard for how data aggregation and sharing occurred, and turn regulatory inevitability into competitive advantage.
I also kept pointing at aggregation opportunities that nobody was filling. In 2016 I asked who was going to build the DevOps aggregation API platform. There were fifty-plus lifecycle APIs — definition, deployment, monitoring, testing, management — but no aggregated layer across them. You could imagine a single aggregated solution that let you define your APIs in multiple formats with API Transformer, deploy with Docker or Heroku, manage with 3Scale, spin up sandboxes, monitor with Runscope, and coordinate the whole lifecycle. The pieces existed. The aggregation across them didn’t. That gap between available components and coherent aggregation has been a recurring theme — the parts are almost always there before anyone assembles them.
By 2025 my thinking on aggregation had shifted in a fundamental way, and the shift was away from technology entirely. For years I had treated aggregation as primarily a technical and UX problem — how do you unify these interfaces well. The 2025 framing asked a different question: do you have enough power to aggregate that platform at all? I had been watching centralized API platform and governance teams operate under top-down mandates to centralize everything, and watching those mandates fail — not because the technology was hard, but because the mandates didn’t come with the resources, education, and political capital needed to actually move people. Aggregating an enterprise’s APIs into a centralized platform runs straight into the legacy of tribal organizational boundaries, the agency of the teams who own the APIs, the absence of any education apparatus to support the transition, and chronically underfunded central teams. Without enough accumulated power in your bureaucratic portfolio to force centralization, the central effort just becomes a bottleneck — real or perceived — and you spend most of your time doing things that aren’t even API-related.
That is the arc of aggregation as I’ve watched it: from 2012’s optimism that aggregators would solve API sprawl across every industry, through the refinement of aggregation versus reciprocity versus orchestration, through the financial-data fight where regulation slowly forced banks toward real APIs, to the 2025 recognition that the binding constraint was never specification standards or integration tooling. Those exist and have for years. The binding constraint on aggregation is power, politics, tribal boundaries, and organizational will. Aggregation is, at the end of the day, a governance problem wearing an engineering costume. The technology to unify many APIs behind one interface has been available for a long time. Whether you can actually get the people who own those APIs to let you do it is the question that determines whether any aggregation effort succeeds.
References
- Adigami Aggregates Analytics APIs Into Single Interface
- API Aggregation For Federal Government With Fed{API}
- Trends In API Aggregation
- API Integration, Aggregation, Organization And Reciprocity With Cloud Elements
- API Aggregation, Reciprocity And Orchestration
- Who Is Going To Do The DevOps Aggregation API Platform
- Hints Of Banking API Regulations From CFPB With Consumer Authorized Financial Data Sharing And Aggregation Rules
- You Don’t Have Enough Power To Aggregate That API Platform
