The Benefits of API Aggregation

The technology world has an ongoing love affair with APIs. The continued hubbub - both within industry sectors, as a way of opening the market - and as a means for bringing new products to market shows no signs of abating. The API - specifically web APIs implemented using REST, but with other competing architectural styles attempting to steal a march - have become the de facto integration mechanism for consuming a provider's services.

However, in this API-enabled world not everyone is content with masses of choice. Even with the advent of low- and no-code solutions, APIs remain a very technical “thing”. Some folks don’t want the hassle of integrating with a myriad of different providers all offering nuances of the same product. There is in fact business to be done here, in bringing together APIs of the same “type” from different providers to offer a unified experience. This is known as API aggregation.

What is API Aggregation?

API aggregation is a fairly simple concept and a reasonably common integration approach when one considers patterns like those laid out by Greg Hohpe and Bobby Wolfe. The basic approach is to take multiple APIs of the same type - let's say, accounting APIs - and create a unified API that can represent all of them. This interface is then implemented in software and the server orchestrates calls to backend APIs based on the calls it receives, before returning a single, consolidated response to the API consumer. Both the request and response payload are specific to API hosted by the aggregator, but broad enough that they can meet the requirements of any of the backend APIs the aggregator mediates calls to.

In such an implementation the aggregator takes responsibility for injecting sufficient context to make the backend call successful. For example, they may store API keys or Access Tokens that are required by the backend API provider. They may also store configuration or profile data that is needed to successfully make an API call to a given provider.

When we consider this in the context of the API Economy it might be difficult to see the attraction of an aggregation pattern. APIs are often cited as a means to give organizations choice in how they consume different products and include them in their stack. Consuming products bundled behind another interface seems nonsensical in this context. However, there are several reasons why API aggregation can make sense for API consumers.

Write Once, Consume Many

Firstly, many organizations want the greatest possible simplicity when they build their stack and simply do not want the overhead of creating and maintaining many software clients. This desire is often coupled with markets where there are business models or technical requirements that demand that many APIs from different API providers are consumed.

The obvious example here is open banking. Banks are obliged to offer account information and payment APIs to the market that are functionality equivalent and for the most part implement the same standardized design. Many organizations choose not to consume from all these APIs, simply because of the difficulty in creating and maintaining the myriad of different integrations to the account-holding banks. They therefore opt to use an aggregator like Ibanity, Plaid or Tink to stand between them, which simplifies their development work by an order of magnitude.

Avoid Regulations

The open banking use case also offers another reason why API aggregation works as a business model. In order to access the account information and payment APIs that European Union banks are obliged to offer under PSD2 API consumers must be registered with their local regulator. Many organizations do not want to go through the process of being a regulated entity, with the red tape, bureaucracy and liabilities it entails - they just want the bank account data. They therefore choose to use an aggregator to avoid the regulations, and still reap the benefits of using a unified API to access the bank account they need to operate their business.

Avoid Lock-In

API consumers may also use an aggregator to avoid the vendor lock-in that may result in tailoring their integration to a single API provider. This is especially relevant in sectors where there are many competing solutions with similar capabilities. Take accounting as an example; companies like Xero and Sage offer access to their platforms via APIs. Aggregators can take advantage of this and build a platform that services all the providers (Apideck’s own Accounting API is an obvious example). API consumers can therefore integrate with many providers without actually having to focus on one in particular, making switching easier in the future.

Network Effects

Finally there is also an implicit network effect from API aggregation. API providers offer increased choice to the consumers of their API, which in turn means that API consumers can offer increased choice to their customers. An example of a potential network effect of API aggregation is payments in open banking. As service providers offering payments offer their services to an increasing number of clients, the number of banking customers who will be able to make payments directly from their account will increase dramatically.

The Open Banking Example

We’ve obviously touched on open banking a number of times in the sections above, but this topic warrants more discussion. The open banking aggregation providers deliver an all-in-one solution that not only absolves organizations from integrating with each account-holding bank or being regulated, but a bunch of other features besides.

Taking the UK market as an example such features include:

• Regulation: As we’ve already said, any organization consuming the PSD2 APIs of the account-holding banks - referred to generically as a Third-Party Provider (TPP) - needs to be regulated by the Financial Conduct Authority (FCA).
• Onboarding: Once regulated and included in the FCA Register TPPs then need to onboard to the Open Banking Directory. This involves acquiring specific certificates (eIDAS), creating a profile on the Directory, creating one-or-more software statements, and using the software statement to create an OAuth client at each account-holding bank.
• Development and Test: With the means to access the APIs at each bank in hand TPPs must then create a software client to consume those APIs. Whilst the UK has adopted standards not all banks are obliged to adopt them. For example, banks like Starling have designed their own APIs. TPPs must therefore develop separate software clients to cater for such cases, increasing the complexity of their stack.
• Operations: TPPs must then run an operation that manages each customer across the banks and successfully correlates data and access tokens with the “consent” an account-holding customer has granted a TPP. They must do this within the rules set for “reauthorisation” where every 90 days they must ask customers to confirm they are still happy with the data the TPP is retrieving from their account.

The point here is that API aggregation can solve multiple purposes. It obviously simplifies the process of creating software clients to call the APIs, but can provide a whole lot more besides. Aggregation is therefore often at the root of platforms and is one key feature of many different products.

The Future: Dynamic Aggregation?

API aggregation is therefore an important pattern in the API world for delivering a business model that delivers significant simplifications for organizations that want it. It is also likely to become more common as the “open everything” agenda continues to grow through many industries and sectors, with the same myriad of APIs from market-serving institutions. Many organizations will continue to require consolidated, market-wide views of the available APIs via a platform that can do the heavy lifting for them.

However, there is the potential API aggregation to evolve by leveraging the considerable overlap with API marketplaces. The concept of a dynamic API marketplace has been around for some time. The idea is that a dynamic marketplace could act as a “broker” for API consumers looking for the best priced or most capable API for a given use case. API aggregation takes this one step further, by providing the brokering capability as a service to API consumers, whilst still reaping the benefits of a unified interface.

This could be an interesting capability in industries like energy, where supplies could be adjusted on a needs basis - as the open energy model promotes - but also provide, for example, carbon offsetting mechanisms based on price, ethical soundness or any other measure published in the market. API consumers could set their “operating parameters” as they see fit and allow the aggregator to choose competing APIs based on the provider most suited to those parameters.

API aggregation is therefore not simply an approach to providing technical simplicity. It is a business model that makes for both feature-rich solutions and all-in-one services for API consumers. As the API Economy continues to evolve and an increasing number of sectors become more “open” the opportunities for API aggregation will only increase.