The Previously Undiscovered Bible of API Companies

Tired of hearing and saying Stripe for Health, Plaid for Commerce, etc? Let's divine the real from the BS with a good old fashioned framework.

In the beginning (roughly the 1970s), tech companies created the heavens (application programming interfaces) and the earth (user interfaces). Thus, the heavens and the earth were completed in all their vast array.

Ladies and gentlemen, we’ve done it. The greatest technological archaeologists of our time have uncovered the tome we’ve all been waiting for, a codex beyond all imagination. We’ve poured over the contents page-by-page, translating each ancient idiom, axiom, and maxim and distilling it down into the purest precepts for your consumption today.

This particular authoritative creed helps us to understand the nuances of the world of API companies, to sort and categorize and stack rank those companies, and to start building cool things via those companies faster.

Preface

What’s an API?

An API is just a delivery mechanism. There are many other ways that software helps users solve a problem - user interfaces (SaaS), bulk processes (flat files), and physical experiences (mail). It just happens that APIs are optimized for developers, rather than the casual internet user or a person in the physical world. To do a little quote-ception from Packy’s great primer on APIs:

On Invest Like the Best, Benchmark’s Eric Vishria describes it simply: people interact with software through Graphical User Interfaces (GUIs), software interacts with software through APIs. 

APIs are defined by a few qualities (usability, security, etc), but by far the most important is simply the problem they solve. An API is a function that does something - retrieves some data, creates an object, or performs a function. As this (excellent) article describes:

Developers don't want to learn your API, they want to solve a problem and move on.

Thus, good API companies that are marketing correctly (although they certainly could fail to fulfill the promises they make about their solutions) start by saying explicitly the problem they solve.

🚩🚩🚩🚩🚩 when you see an API company that doesn’t clearly state the problems they solve as the first thing you see on their website.

In addition to saying they solve a problem, actually fulfilling that promise is fairly important. Does their API actually do what it says it will do all the time without issues? To that extent, reliability and coverage are often underlying sub-qualities worth examining, although not always applicable.

Beyond that promise of a solution to a problem I may have, an API is defined primarily by the ease of use and cost:

• Ease of use: Are the concepts inherent to my API simple to learn? Is authentication safe, yet uncomplicated? Can I test without paying? Can I solve increasingly complex problems as my needs increase?

• Pricing: What is the cost associated with using this tool to solve my problem? How does it compare with solving this problem with another API or with a different delivery mechanism? What is the cost in terms of developer hours to build to this API format?

• Developer intangibles: There are tons of niceties that an aspirant API company can do to go above and beyond. Developer documentation is a product in and unto itself, ranging from content in Wordpress or Readme to truly unique experiences built using Jekyll or Gatsby. Software development kits (SDKs) and sample code can accelerate and orient these key users. Vibrant communities in Slack or Discord bring together like minds and allow for cross-company pollination. Eager, active support via solutions architects help customers make the (sometimes huge and intimidating) jump from 0 to 1  

It’s worth noting that these last three factors (and any other factors!) do 👏 not 👏 matter 👏 if the problem solved with an API is not a common, useful problem to be solved. We can arrange this into a new age hierarchy of needs:

Just as Maslow saw with his theory of motivation, users move up the hierarchy as basic needs are met. If an API does not have a problem space resonant to customers, it does not matter if it has cheap pricing. Likewise, if the problem space is resonant, but coverage is insufficient to solve it, great developer documentation is rarely going to convince someone to use that solution, barring outright customer ignorance or vendor deception. 

As an example that we’ll dig into more later: when Plaid was starting out and competing with Yodlee in regards to financial account aggregation APIs, it clearly had a problem space resonant to customers (Yodlee had proved this). How did it differentiate and pull ahead of Yodlee? 

As our HackerNews friends point out, they focused on the next levels of the hierarchy:

Coverage and reliability:

Pricing:

Ease of use:

Classifications

Consider this your warning - this is an API company bible and bibles are long. If you’re not much of a bibliophile and want a summary style view, this handy chart outlines the different classifications of API products, so that you can act like you read the whole article when you’re having fun dinnertime conversations with friends about it.

---

Headless Businesses

The simplest style of an API company is to look at a traditional business, squint your eyes a little, and slap on an API as a novel delivery mechanism. By doing this, you’ve opened yourself up to the “tech-forward” subdivision of your customer base. Extrapolating this out, your services can also be sold to software that sells to those customers (i.e. the applicable “vertical SaaS” of an industry) leading to potentially massive distribution as that software scales.

But there can be some tension here - these headless companies live dual lives, trying to build incredible products for developers, but also execute on the operational competencies needed to be competitive in the market they operate in.

This strategy is also extremely copyable! Since APIs are popular, many companies are creating developer experiences and opening up their microservices. This means, in the long run, it’s highly likely that it’s not that differentiated to be headless. Traditional players will eventually get around to modernizing (at least in a half-hearted “we tried” attempt) which will encroach on any intermediary players or headless startups. So the best way to view this classification of API companies is through the lens of a first mover advantage: “Can they get to a sufficient market share by being API-first to build something differentiated before scaled legacy players slap on a replacement-level, good enough solution?”

Thus, applying Maslow’s pyramid here, we see the competition typically concentrating on price, ease of use, and developer intangibles. The lower levels are hard to differentiate on for headless businesses:

• Resonant problem: the core business underlying a headless API product is generally a well-defined problem space. For example, pharmacies are already ubiquitous today and solve the need for patients to receive their prescriptions from their doctors.

• Coverage and reliability: given that the APIs of headless businesses are constrained to the functions of the business itself, typically coverage and reliability are not differentiators.

Examples

Some example of headless APIs in banking, pharmacy, and providers

Banking

Need to read the fine print next time I go to the headless banking convention

Banks have existed for a really long time and over the course of that long existence, have gotten quite complex, offering a number of cool services - checking, credit, loans, and so much more. There are many bank customers that want to use those services without having to do a phone call, in-person visit, or email. By slapping a simple API on a bank, viola - you’ve created headless banking (more commonly known as banking-as-a-service or BaaS).

There are several varieties, but the most direct BaaS plays are where the most aggressive neobanks have secured a banking charter (generally by purchasing a bank) and created API programs to expose their core banking functions in a developer friendly way, such as Column or Cross River. Similarly, major banks like J.P. Morgan or Citibank have opened up nascent API programs.

Compared with BaaS startups that mediate between fintechs and banks (who we’ll tackle in the on-ramp section), they lag a bit in terms of feature parity (and cost, which is surprising when you’re “cutting out the middleman”), but if they do catch up, you have to imagine it will suck the air out of the room for the intermediary variant. However, they are faced with the aforementioned tension - can they balance the complex operationalization of all the bank processes and still maintain a core competency of creating incredible developer experiences?

At first glance, all the BaaS APIs looked the same to Little Bobby Fintech, but he soon learned his lesson

Healthcare

Relative to banks, healthcare (as we think about it today) is a newer concept - while founding fathers like Hamilton and Jefferson were debating the need for a central bank way back in the US early days, it wasn't until Jimmy Carter that we had a president born in a hospital. However, traditional healthcare institutions still first evolved in the brick-and-mortar era, which means that digital alternatives are now becoming popular.

As we see in banking, a subset of these have taken the headless approach. For instance, Truepill offers a robust API for the full prescription, dispense and refill lifecycle, serving as the main (perhaps only?) headless pharmacy in the US. As teleprescribers and other DTC virtual first care organizations need a way to prescribe without the overhead of the Surescripts network, this tech-forward option meets their needs well.

Similarly, we see virtual practices like Wheel and SteadyMD provide a headless clinician workforce, helping organizations that need on-demand capacity for telehealth to use simple APIs (in addition to other tools) to embed that capability in their software.

It’ll be interesting to see how incumbents play defense against these headless entrants. Will CVS and Walgreens expand their API programs to embrace more direct connectivity with virtual first care organizations? Will traditional hospitals and clinics attempt to open new revenue streams by API enabling their existing clinician workforce? The future feels less certain here, which makes me more optimistic about the upside of the headless APIs we see today.

However, I’m not so sure this class of API company is truly differentiated and defensible (at least by virtue of their API functionality). As the Health API Guy, do not get me wrong - I like all API companies. However, the generational API companies we see today are companies whose value adds are simplicity and access via an API layer to solutions they do not own. By decoupling themselves from creating value by solving the problem, they enable themselves to focus single-mindedly on creating value of simplicity and aggregate access in a way that the aforementioned traditional companies (SaaS, big tech, traditional healthcare, or financial institutions) generally struggle to do or are incapable of doing due to competitive forces. So, to summarize: the most well-known API companies have a core competency not of building the solution to a customer’s problem, but of simplicity and access when exposing pre-existing external solutions.

On-ramps

Our next style of API company is one we’ve chatted about before in-depth, so some refresher content:

Ubiquitous networks are powerful, even when the underlying technology is not. When one can assume that a given workflow can be fulfilled with little to no variation at a national scale, it can be treated as a commodity and built upon. The payment rails run on really ancient formats, but the fact that it can be used universally trumps the weird nuances and legacy standards. With payments networks fully ubiquitous (all banks, ranging from Citi, JP Morgan, or Wells Fargo down to the long tail of community banks and neobanks, participate in the payment rails), we see innovative companies like Stripe, Finix, or Moov acting as on-ramps, trading a simplified experience for some fees so that businesses that wish to utilize these commodities can do so with lower overhead and investment.

An on-ramp API company looks at a pre-existing network (rails) with pre-Internet standards, technology, and (importantly) developer anti-friendliness and exposes that access via a simple, easy-to-use API.

These API companies perform a specific (but fairly obvious) form of technical arbitrage:

1. Large networks, once built and ubiquitous, offer unique capabilities at a regional or national scale that cannot otherwise be replicated

2. However, a large network with many nodes takes a long time (at best) to upgrade capabilities, as there are always laggard nodes. To quote Tom Noyes, “…as networks scale, they become more rigid and their ability to create NEW services (beyond payments) diminishes.” Frankly, as a ubiquitous network, it’s a complex series of negotiations, incentivization, fortuitous regulation, and mild blackmail to get new features deployed, as you’re essentially building a new network as you convince hundreds or thousands of stakeholders to change.

3. New entrants struggle with legacy standards that require an expensive, elite pseudo-priest class of experts with deep knowledge of the ancient ways

4. On-ramp company senses the collective pain of the new entrants, builds or hires expertise to normalize and standard the nuances of the network, and exposes in a modern way.

Older is better here, as the size of the opportunity is directly correlated with the pain of DIY building. If a network is built with modern tools, formats, and onboarding experience, there’s just less opportunity to arbitrage, as developers will simply choose to use the network itself rather than an on-ramp. Conversely, if a given industry hasn’t yet developed a ubiquitous national network (looking at you, education), you can’t create an on-ramp company - you need to go actually do the difficult work of network building.

I don’t want to be flippant, but on-ramp products are relatively easy to make. You completely sidestep the hard, meaty work of network building and instead milk a few basis points off of already ubiquitous networks. The older and more ubiquitous the network, the better for those on-ramp companies, as the more ancient and difficult it is for new entrants to play in those ecosystems and the more value you add simply by turning it into JSON.

This leads to an unavoidable vulnerability for on-ramp companies - the opportunity for arbitrage evaporates to a large degree if the network decides to and is able to upgrade the underlying standards in play. If Visa makes it dead simple and easy to integrate payments directly, my pain as a developer hypothetically goes away, and Stripe is disintermediated. Luckily, that narrative is not always how things play out. As we saw in Maslow’s Hierarchy of API Needs, an excellent API is more than just JSON. It’s easy onboarding, clear documentation, great tools, and any number of value add features that the network itself is generally too large, slow, and/or enterprise to actually create and market. Thus, Visa does have payment APIs, yet Stripe still exists - they both address the same problem space, but Stripe outperforms on the higher-order features of the pyramid.

You mess with the godfather, you get slapped around, even if you’re Visa

Similar to headless businesses, the level of competition for on-ramps is generally at the ease of use and above:

• Resonant problem: the existence of the underlying network validates and defines the problem space. Visa facilitates payments. Carequality facilitates the retrieval of health information. On-ramps cannot differentiate here, as they are limited by what the network can do.

• Coverage and reliability: the access of an on-ramp is a direct pass-through of the underlying network, so all competing API products have roughly the same coverage and reliability.

These products are quite copyable and subject to heavy competition as a result, like Finix choosing to go head-to-head with Stripe recently. Differentiation becomes hyper-focused on usability (more value-add features) and pricing (driving towards commodity over time). If, however, any particular company can hit a sizable market share, they often seek to claim unique superpowers that, if valid, make them sticky and hard to dislodge, such as Stripe’s famed fraud detection. Beyond those superpowers, most on-ramps use their initial success to diversify into broader offerings, such as complementary SaaS or other more defensible types of API products. This latter move is a really smart one in my opinion - using the initial success with an ultimately replicable product as a launchpad to stronger moats.

Examples

Payment networks

The elephant in the room (mafia in the room?) is Stripe. Their initial product and moneymaker is and was an API for payments, overlaying the credit card networks and their inscrutable protocols with a nice API. Their excellent team, marketing, and quality of execution mean they’ve amassed a high enough market share that they’ve unlocked fraud detection that’s significantly better than a challenger can offer (supposedly). Realistically, though, switching costs are the primary moat for Stripe (and most on-ramps), as few companies are willing to prioritize reinvesting in a “solved” problem rather than working on the next big initiative. Beyond that, they’ve diversified into broader secondary API product offerings with stronger moats, such as Stripe Atlas for company formation, Stripe Tax for multi-jurisdiction tax automation, Stripe Identity for identity verification, or Stripe Financial Connections (more on that below). This diversification and movement towards being a “one-stop-shop” is a smart strategy, because (as detailed above) their core product is actually quite replicable on paper, despite their reputation and prowess.

It’s worth noting the oft-forgotten domestic counterpart to Stripe, Square. Square overlays the credit card networks’ intricacies with easy-to-use non-technical solutions: point-of-sale devices, virtual terminals, and no-code website creation. They dance the same dance as Stripe, only for a different audience. They do have an API, but that’s entirely secondary to their core go-to-market. Regardless, they certainly are a clear example of the type of physical and SaaS modality on-ramp company that often co-exists alongside on-ramp API companies, a template we’ll see again shortly.

In terms of pure-play competition, Adyen and Checkout.com both seem functionally identical to Stripe as core payment on-ramp products, offering modern payment APIs with crisp, clean developer documentation and tooling. They both have more of an international focus (Adyen defaults to euros, for instance) and Checkout.com in particular seems to focus on large enterprise clients such as Sony and Shein.

Communication networks

Twilio owns the most mindshare in this space, overlaying the pre-existing mobile phone carrier networks to allow developers to send SMS, voice, and other communications. The standards those networks run on are pain incarnate: SIP, XMPP, RTP, and GSM, so there’s high value to abstracting to an API level for developers. Like most on-ramp companies, it has a slew of copycat followers: Bandwidth, Nexmo (now Vonage), Plivo, etc. Economies of scale aren’t as poignant here, but there’s a handwavy argument to be made that Twilio has better reliability, scalability, and security (what they call their “Super Network”) as a result of being the market leader. This is thematically similar to Stripe’s fraud detection claim. Similar to Square in regards to Stripe, there is also a slew of SMB-focused SaaS on-ramps for similar, such as Front, that offers a user interface instead.

Communication networks are varied so you see other examples of on-ramp APIs like Lob for mail, SendGrid and MailGun for email, or Shippo for shipping, all with similar dynamics in regards to competition (copyable business model) and moats (economies of scale and high switching costs).

Health payment networks

Healthcare’s largest and most ubiquitous networks are oriented around the core financial interactions between providers and insurance carriers for eligibility, claims, and claims status. X12, the underlying standard, is ancient and gross. Thus, we see on-ramps in Change Healthcare, Availity, and pVerify. There isn’t a clear market leader here, with pVerify offering more normalized and standardized content in their API, but Change and Availity offering significantly cheaper pricing.

Note: Eligible also supposedly operates in this space and has some startup energy marketing. However, their documentation is closed and no one I’ve spoken with has really been able to engage them (supposedly they’ve been replatforming), so I’m hesitant to include them.

Health data networks

Healthcare uniquely has built networks for competing institutions to share their data (this conceptually does not exist in banking or other industries, as far as I know). These interoperability networks (Carequality, Commonwell, and eHealth Exchange) use dense XML standards (XDS, CDA) that are a bit cumbersome. As a result, we see that same technical arbitrage with a slew of on-ramp options: Health Gorilla, Kno2, Particle Health, Redox (Record Retrieval), Zus and many more. In terms of mentally mapping these companies to their payment industry parallels, Particle and Redox have taken more of the Stripe API-only approach, whereas Health Gorilla, Kno2, and Zus largely play the role of Square, as they offer APIs but have seen more success with their SaaS portals.

Travel networks

I think at this point, you’re probably getting the picture when it comes to on-ramps; however, given that the situation in the travel industry is a little less well-known but utterly fascinating, we will soldier on with one final example.

Airlines in the early 1960s could not handle the volume of people trying to book tickets, so they created Computer Reservation Systems (CRS) to allow ticketing agents to search for flights using digital inventory, make reservations, and confirm them via computer terminals. These systems were very successful and access was expanded, first to travel agents, but then to the general public, creating Global Distribution Systems. The first and most famous of these is Sabre, created by American Airlines, but now a public company.

GDS are massive networks, but the standards used are ancient, even with a new push by the US government to get everything onto an XML format, New Distribution Capability (the travel industry is truly innovative when it comes to naming their standards and systems).

Duffel is the arbitrageur de jour here, giving a nice easy REST API instead of these legacy standards and formats. The size of opportunity seems smaller than our other examples, in that the switch to XML reduces developer pain, but also the need for paying someone or fetching health data is likely slightly more common than booking a flight. That said, Sabre is doing 42,000 transactions every second, so even a marginal slice of that volume could be a good business. It’ll be interesting to see if competitors pop up alongside Duffel.

---

This article ended up being quite the beast, so we’ll adjourn here temporarily and wrap up in part 2 (aka the New Testament, aka the Tale of the Aggregators).

---

Given the length, tremendously grateful to the editors who helped out with this particular article, so here they are. Please click on their links and support their companies:

• Abe Clark of influenceli

• Ben Lee of Quite a Few Claims

• Colin Keeler of Kiva

• Erica Jain of Healthie

• Garrett Rhodes of Redox

• Hamna Nazir of Formsort