Vertical APIs
Banking, healthcare, telcos, how API-first businesses are now eating old industries by connecting and abstracting legacy software and outdated protocols.
At Point Nine, we’ve been partnering with API-first businesses since our investments in Contentful and Algolia in 2012/2013. As P9 alumnus Clément explains in this post from 2016, the rise of APIs has allowed software developers to use best-in-class software components to build software faster, cheaper, and better. The picture below is from 2016, but it shows that already back then, a big part of the software stack had been “APIfied”. This led to the creation of multiple very large businesses in each of the boxes below. By now, there are many more.
The advent of APIs is not only reshaping the software development industry, but it’s also reshaping older industries like banking or healthcare. In this post, we try to take a step back on how APIs are “eating old industries” and try to review the opportunities and challenges for these businesses that we call “Vertical APIs”. The typical taxonomy is that “horizontal” software refers to software that any industry can use; vertical only addresses one.
Vertical APIs
In computer programming, an application programming interface (API) is “a set of subroutine definitions, communication protocols, and tools for building software (source)”. “To put it simply, a good API makes it easier to develop a computer program by providing all the building blocks, which the programmer then puts together.”
Even more simply, APIs are like LEGOs to build software. The most basic example is Stripe. Any developer that wants to process payments can use Stripe instead of building their own payment infrastructure.
APIs differ from the previous generation of SaaS software to the extent that it is:
- Built for the developer: you need to be a developer and write code to use APIs
- Modular: developers can decide to use only a few endpoints of the APIs depending on their needs
- Headless: code is the user interface. This enables developers to build dedicated Graphical User Interfaces (GUIs) on top of these APIs that are customized for their own applications.
Ten years ago, the founder of Mashape wrote this (visionary) post where he explained that the advent of APIs would lead to what he called the “Industrial revolution of software”.
Until a few years ago, most companies were developing heavy, monolithic applications weighed down by proprietary code. Applications can now be decoupled into smaller components, creating thousands of microservices that communicate and work together via APIs. […]
In Ford’s time, electrification represented the underlying requirement for innovation and the assembly line was the practical combination of electric and human power, resulting in massive improvements in productivity, efficiency, and creative cycles. Today, cloud computing is the electrification of the software world, and APIs and OSS are the resulting means of production.
Fast forward ten years, software has carried “on eating the world” and there are developers in every industry, even the oldest ones. Consequently, APIs can now reshape each of these old value chains. Let’s get more specific below.
A few examples of Vertical APIs
The telco and the banking world were the first “old industries” to be addressed by Vertical APIs. Twilio made it easy for any developer to build calling / SMS experiences as part of their applications creating a layer between TCP/IP (the protocol of the internet) with the traditional telco protocols (SIP, GSM, XMPP, RTP). While its gross margin isn’t the typical software margin, Twilio makes >$1Bn in revenues today and is worth multiple $Bn.
In the banking space, Plaid, Tink, or TrueLayer took advantage of the open banking regulation (eg. PSD2 in the EU) to enable developers to fetch transaction data and trigger payment directly from banks’ back offices. This has enabled developers to build new experiences on top of the existing banking infrastructure.
More recently, in the healthcare space, (P9 Fam member) Nexhealth is offering an API that enables any app developer to access patient’s data stored in the Electronic Health Records used by the doctors. Vital, another P9 Fam member, is enabling developers to access biometrics data collected by labs or wearable devices.
In the passenger travel space, Duffel is leveraging the advent of the open protocol NDC to allow any developer to offer travel services in their applications.
In the EV space, eDRV, Ampeco, or Enode are also leveraging an open protocol in the Electric Vehicle space called OCPP to offer an API to access (and sometimes control) EVs or EV charging stations.
In the financial market space, Alpaca and Lemon.markets are offering APIs to allow developers to execute trades directly through code but also serve as infrastructure for trading applications.
In the ERP space, our portfolio company Procuros is simplifying the exchange of data in-between ERPs for businesses involved in trade relationships.
Merge.dev (that recently raised a $55M Series B) found early traction by facilitating access to HR APIs (connecting to HRIS or payroll APIs) and has since then become a powerhouse at building multiple APIs connecting software ecosystems.
Codat (raised $176M) fetches data in various accounting software like Xero or Quickbooks or other ERPs to allow developers to build new software that requires access to accounting or commerce data. This can be building new credit engines for example. Several other businesses are centralizing commerce data such as Alloy (raised $16M from a16z) or Rutter (raised $27M from a16z) which focuses on helping e-commerce businesses connect all the systems they use.
Shippo centralized access to various logistics providers (esp. in the US) and made it very easy for anyone to offer goods/services that require a logistic service. In particular, the e-commerce industry.
Below is a table with each of these examples and some of the incumbents they are going after, the truth is there are probably many more. If you’re building one, please reach out to us, happy to learn more :)
In the next parts, we’ll highlight a few of the opportunities and risks we’ve brainstormed on, speaking and partnering with some of these Vertical API startups.
Opportunities
1) Leveraging industry-wide protocols with modern technologies and offering new software possibilities on top
API-first businesses are often built on top of open protocols that existing industry players have adopted to standardize communication between each other. SIP/GSM in telco, PSD2 in banking, NDC in passenger travel, and OCPP in EV charging are all examples of these open protocols. But this standardization is rarely enough on its own to make things straightforward for developers. The opportunity often lies in leveraging modern technologies like REST/GraphQL to build a unique developer experience while offering new possibilities on top of these open protocols. Ampeco in the EV charging space is leveraging the OCPP protocol to connect to EV charging stations but also offers additional features like smart charging, billing, and user management on top. Plaid not only offers access to banking data but also lets developers trigger payments from banks’ back offices.
2) Connecting fragmented software ecosystems
In cases where an industry-wide protocol doesn’t exist, Vertical API businesses can still emerge but need to either i) build integrations with existing software ecosystems from the getgo and build a unified data model for the whole industry; and/or ii) find wedges in their respective industry by offering complementary value on top of these integrations usually through a complementary SaaS offering to get access to industry-wide data.
Nexhealth first had to build a sales & marketing solution for healthcare professionals (think “Hubspot for doctors”) that connects on top of multiple EHRs before offering an API for anyone to access EHR data. If you’re curious about their “Secret 3-step Master Plan”, have a look at this (great) post.
From a “defensibility standpoint” (more on that in the risk part), we could argue that Vertical APIs that build their own integrations build more barriers to entry than their counterparts that leverage industry-wide protocols.
3) Going after different personas initially with a narrower offering and an innovating business model (free?)
As they start, these Vertical APIs often have a much less complete software offering than their SaaS counterparts but the modularity of APIs makes it such that they can afford to i) sell only a small subset of the broader offering of their SaaS counterparts and ii) leverage a free offering or usage-based pricing to lower the barriers to adoption. They can also iii) go after personas that are new in the industry and have lower expectations. A good example of that is Alpaca or Lemon.markets, which offer a trading API to individual traders that have a lower willingness to pay than the typical trading institution but are often as well-versed in software development.
4) Disrupt existing software incumbents
Long term, the combination of i) technological disruption (API-first), ii) business model innovation (free / usage-based pricing), and iii) going after different personas initially (developers) is a good recipe to disrupt the existing, very large, SaaS incumbents that are i) not great at building software, ii) slow to innovate on their business model, and iii) don’t know how to speak to developers.
Duffel is trying to go after Amadeus ($2.7bn in revenues, >$20bn market cap), Alpaca is going after Interactive Brokers (ca. $3bn in revenues, >$30bn market cap) and Plaid is potentially very disruptive for payment companies like Visa. Visa saw it coming and bought Tink for $1.8bn and tried to buy Plaid for >$5bn, before being prevented from it by the US regulator.
Looking at the revenues and the market cap of these incumbents, it’s clear that these are great, venture-scale opportunities to go after!
5) Creating a new layer of abundance while leveraging scale effects
Just like marketplaces standardize and centralize the access to the supply of an industry, Vertical APIs create a connectivity layer that centralizes and standardizes the access to an industry’s possibilities or software (payment, trading, EV charging, travel booking). The beauty of this model is that the industry-leading player can benefit from strong scale (network?) effects: the more coverage of possibilities (API endpoints) the API has, the stronger the value proposition of the API-first business. By standardizing this access, they create a new layer of abundance enabling anyone to innovate on top of them. Ben Thompson’s Aggregation Theory from 2015 explains that very well here.
Building Uber was made possible thanks to the advent of payment and map APIs. Now, let’s imagine all the businesses that could be built on top of EV charging, travel booking, or healthcare APIs as these industries’ possibilities are made available to anyone through an API :)
Challenges
1) Vertical APIs take time to build: the coverage of data/use cases is critical
What comes with opportunity 4) “creating a layer of abundance by making many use cases available through a single API” also comes with the negatives of having to have a good level of feature completeness before being able to provide enough value to developers in order to justify adoption. Just like building critical mass is required for marketplaces’ flywheel to kick start, the initial MVP of Vertical APIs requires a significant initial investment to cover enough endpoints. As an example and without knowing all the details (we’re not investors in the company), it seems to have taken a bunch of months for Duffel to start going live in the passenger travel space.
2) Building moats
Open protocols are free for anyone to leverage and build on top of, including startups but also existing industry players. The APIs that will build strong, defensible businesses will not only need to standardize the access to the data layer but also build value-added features on top of it, which the aggregation of data enables. In contrast, Vertical APIs that have another wedge (like distributing SaaS software) to gather industry-wide data instead of leveraging an open protocol are usually more defensible.
3) Indirect distribution, ACV sizes, and graduation risk (build vs. buy)
Another way to look at vertical APIs is that they rely on developers to distribute the service they offer: banking, travel, or logistic services. To that extent, the Vertical API providers need to bet on the fact that the app developers will be very successful in not only building but also monetizing their own applications to justify significant ACVs. Both Whatsapp and Uber had 7-digit contracts with Twilio to verify the identity of every new user by sending a code through an SMS. But how many apps are as big as Whatsapp?
Relatedly, a developer/company that becomes very successful will be tempted to churn and build directly on top of the open protocol if the vertical API provider does not have enough breadth/ industry coverage, isn’t providing enough value on top, or is simply asking for too much money (vs. the cost of replicating it). This creates what we usually call a “graduation risk”.
In 2017, the Uber contract represented 12% of Twilio’s revenues (ca. $3M ARR contract) and Twilio’s stock started plummeting when Uber and Twilio started distancing themselves from Twilio (TC article from back then here and an excerpt below).
(source here)
Customers might also be tempted to build (vs. buy) if they’re mainly relying on a single use case and/or data that a vertical API is providing.
4) Business model risk: “double take rate” risk?
Initially, open protocols were created to enable the standardization of information exchange between industry players… for free. Airlines agreed on NDC partly to be able to communicate with each other without relying on GDSs like Amadeus and Sabre. In a way, a vertical API like Duffel could look just like another more dev-friendly intermediary between airlines. Innovating on the business model (for example not monetizing on transactions but mainly on ancillary services added on top for example) might be the only way to justify usage in (low margin) industries that are fighting hard to reduce their dependency on software intermediaries.
5) Replacing existing data exchange protocols
APIs are not the first attempt at solving data exchange/communication problems between industry players. A previous attempt that exists since the 70s is called EDI. Businesses sometimes have dedicated significant resources for years to leverage older technologies like EDI or even built direct integrations that they need to maintain. Even if these don’t offer the same functionalities (endpoints) and ease of use as a modern API, there’s a “sunk cost” that is sometimes hard to swallow to embrace modern, web-based, APIs. We often see such dynamics in old(er) industry supply chains that have invested significantly in EDIs to make ERPs speak to one another, sometimes with questionable success ;)
If you’re building a vertical API business, please get in touch, we’d love to learn more.
Ricardo and Louis.
Obrigado to our colleague Alex George, for reviewing earlier versions of this post. Merci also to Maitham Dib and Patrick Thelen for adding new great perspectives to it.
