How defensible are the network effects on API platforms?

Recently we’ve seen an explosion in different API-based startups: Belvo (Plaid for LatAm), Decentro (Plaid for India), Finch (universal payroll and HR API), Flexpa (API platform to access health plans), Kard (for card issuers to connect with merchants to offer rewards), Makini (API for enterprise asset management), Palenca (payroll API for LatAm), Pelm (developer API for the energy grid), Railz (connects to accounting software), Realize (integrate apps with retail brokerage accounts), Seam (API for IoT devices), ShoppinPal (integrating multiple softwares for restaurants via APIs), Terra (connects apps to fitness devices). These apply the ideas of successful API platforms like Plaid (banking), Twilio (communications) and Zapier (connecting and automating apps) into new countries and new applications.

In essence, API platforms provide a way for customers to more easily integrate with multiple service providers’ offerings. Put differently, they provide the “information pipes” for the needed connections. Thus, instead of a customer (say, a fintech company) having to build their own integrations with all the service providers (in this case, potentially thousands of financial institutions so that all the fintech company’s customers can transfer information from their accounts to the fintech company), they just have to integrate once with an API platform (Plaid), which takes care of all the “plumbing”.

On the surface, API platforms look like amazing network effect businesses. For example, Plaid claims it connects over 5,500 fintech applications (Acorns, American Express, Betterment, Coinbase, Venmo, etc.) to over 12,000 financial institutions in the U.S. alone (big banks like Chase, Wells Fargo, Bank of America, as well as smaller banks and credit unions). One quarter of all U.S. adults has already connected an app with Plaid, and that number grows daily.

But do these API businesses really have powerful and defensible network effects? Indeed, are they really platforms at all?  

One-sided outsourcing service vs. two-sided platform

To answer these questions, it’s useful to take a closer look at Plaid. One can think of Plaid as having gone through two stages.

In the first stage, represented in figure 1 below, Plaid was essentially a one-sided outsourcing service. Specifically, it took on the work of any financial app wanting to allow its customers to link the app to their bank accounts. This might be so the app could verify their account balance, or analyze their recent transactions, for example. We say “one-sided” because this was typically done without the banks actively participating. For example, Plaid would offer a virtual browser connected to the bank’s website, where the consumers of the fintech app (say, Robinhood) could log into their bank account for the purpose of sharing some of their bank account information with Robinhood. After the consumer logged in, Plaid could scrape the account details, bank balance or past transactions off the page, and send the information back to Robinhood on behalf of the consumer.

In this first stage, when the banks were completely passive, defining a network effect doesn’t even make sense: we can’t talk of more banks joining Plaid. Instead, Plaid’s main defensibility came from the fixed costs of building the virtual browser and the scraping technology that worked with each of the fintech customers’ banks, including updating it every time a bank changed its user interface. There was certainly no defensibility from network effects. The main task was to recruit fintech apps that wanted to outsource the work of linking to their customers’ bank accounts to Plaid. By not having to also get banks on board, Plaid solved the chicken-and-egg problem, and was able to focus on just attracting fintech apps initially. This also means that given our definition of platform businesses, Plaid was not a platform business at this stage.

In the second stage, represented in figure 2 below, Plaid got the banks to make deliberate efforts to provide improved and continuously updated APIs. This ensured the linkages between fintech apps and banks always worked, even when banks changed their user interface, and that customers’ data did not have to be saved by Plaid (which was better for security reasons). An example of a bank working closely with Plaid is U.S. Bancorp, and their agreement ensures that the bank’s permissions hub and Plaid’s portal will be constantly in sync. The impetus for U.S. Bancorp (and other banks) to do this is that they compete to offer their customers the best service: an increasingly important part of that is ensuring they seamlessly and securely work with the multitude of fintech applications their customers expect to be able to use with their bank account.

The result is that at stage two there is a cross-side network effect running between fintech apps and the banks. The more banks join Plaid (and keep their APIs working), the more valuable Plaid becomes for fintech apps since their customers can link their services to their bank accounts smoothly. The more fintech apps join Plaid, the more attractive it becomes for a bank to make an effort to integrate with Plaid, since the investment in keeping their APIs updated and working smoothly has a greater payoff for their customers.

Once banks start making relationship-specific investments in Plaid (like U.S. Bancorp), these cross-side network effects provide real defensibility. But the defensibility is somewhat limited in our view. A key driver of Plaid’s value is that many banks rely on arcane information technology systems, which require significant effort to connect or integrate with. As the banks’ systems are updated, they will likely be able to provide standardized APIs that will also work with Plaid competitors, and indeed may mean that eventually fintech apps can bypass API platforms altogether. Moreover, Plaid does not provide discoverability: fintech apps and banks do not use Plaid to discover each other, which further limits the scope for network effects.

It is worth contrasting Plaid with another API platform, Zapier, which has more compelling network effects in our view. Zapier helps customers (mainly business users) connect apps like Gmail, Slack, Dropbox, Discord, Twitter, Zoom, Airtable, Stripe and so on, via APIs, so that they can more easily move information between these apps. It supports over 3,000 such apps and over 1 million users. Users cover a wide range of firms (and their employees) that want to automate tasks that work across combinations of different apps (called zaps). An example of a zap would be monitoring whenever a Twitter profile tweets something that mentions the company’s name, and Zapier sends a notification to a Slack channel so that employees can follow up from the company’s twitter account if necessary. Cross-side network effects arise between users and apps.

In contrast with Plaid, the integrations that an app may need to work with other apps are not so easily standardized. This is because of the difficulty of different software combination working together seamlessly. With thousands of apps, there are millions of different possible integrations between any two. As a result, Zapier needs to rely on apps to self-serve to a certain extent, joining Zapier and constantly updating their APIs. As Zapier says on their website, “two new apps join our Platform every day, and your Zapier integration connects you to them.” Zapier also provides discoverability through their app directory, which means the network effects are not limited to integrations. Apps can also get certain benefits, including being promoted by Zapier, by earning a higher status in Zapier’s partner program. An app’s status level in the program is determined by how many people use its integration and the “health” of the integration.

In addition to a stronger and more defensible cross-side network effect, Zapier also enjoys a same-side network effect between the apps themselves, given they have to work together. An app is more likely to join Zapier, the more other (complementary) apps are on Zapier, because that means there are more apps to integrate with, which in turn increases the value of the app in the eyes of its users. Finally, unlike the banking APIs on Plaid, there is almost no limit to the number of ways different apps could work together, especially as new apps are added every day. However, similarly to Plaid being vulnerable to banks creating their own standardized APIs, Zapier is vulnerable to app providers (especially the large ones like Dropbox, Notion, Slack and Zoom) providing their own APIs to facilitate integrations with other complementary apps.

Concluding thoughts

In evaluating new startups that claim to be API platforms, it is important to analyze each in detail to understand the power and defensibility of their network effects, if any. For network effects to exist and provide defensibility, the service providers involved (e.g. banks in the case of Plaid, apps in the case of Zapier) must make relationship-specific investments (e.g. customizing and updating APIs for that particular platform), which they wouldn’t want to duplicate for a rival platform with significantly fewer customers. Otherwise, if the service providers don’t have to take any active (and costly) steps to participate on a given API platform, then the latter looks like a glorified outsourcing service – it might benefit from important scale economies, but certainly not from network effects.

Moreover, like for any business, it is useful to evaluate the scope for extending the network effects on these API platforms, in order to enhance growth and defensibility. One way in which API platforms like Plaid and Zapier can do so is by offering a service to their customers’ customers, i.e. to end-users. For instance, Plaid has recently begun offering U.S. consumers the ability to monitor and control the information that is being shared by the banks and fintech apps they use. By forming a direct connection to end-users, Plaid can add a third side to its platform, and build a stronger moat around its business. For instance, it could go further and enable consumers a way to discover fintech apps that work with their bank accounts, which would create an additional network effect between consumers and fintech apps.