Perspectives: “Plaid for X” – API-first companies beyond fintech

Fintech has laid the blueprint for successful API-first businesses

API-first companies like Plaid, Tink, TrueLayer and Stripe have grown in popularity in recent years for their ability to seamlessly integrate financial data into various applications. Offering robust APIs (application programming interfaces) their success not only showcases the power of a developer-centric approach but also underscores the transformative impact of technology on the financial sector, from banks to other institutions. Empowered by micro-service architecture and an explosion of growth in the fintech market, these companies were the tech darlings of the 2010s, and remain critical to most modern products. To oversimplify, these platforms innovated by offering:

• Convenience: One of the pivotal elements underpinning their success is the convenience they provide to both developers and end-users. Developers no longer have to spend countless hours building integrations with each individual financial institution. Instead, they can use the API provided by the API-first company and access data from multiple financial institutions at once.
• Security: Another factor that contributes to their success is their focus on security. These companies have to comply with strict regulations and employ advanced security measures to ensure the safety and privacy and privacy of users’ financial data.

Analytics: These businesses also enrich their offerings with value-added services such as data analytics and insights, empowering users with data-driven decision-making tools.

But while API-first businesses were rooted in fintech, the seeds have spread to other orchards, and we’re seeing a new rise of API-first companies in a wider variety of sectors. In this context, we seek to understand what structural factors favour defining-category businesses targeting markets with an API-first approach, as opposed to traditional application software.

What insights can be applied to API-first companies beyond fintech?

While convenience, security, and analytics have become table stakes for many API-first businesses, certain market-specific structural factors create optimal conditions for the emergence of an ideal neutral intermediary (some would call ‘Switzerland’) player. We believe successful API-first companies will have a subset of the following characteristics:

Market fragmentation on both sides

Case study: Stripe – allowing merchants to accept payments from anywhere.

Connecting one thing to another is fairly straightforward. API-first companies exist because connecting one thing to many things is harder. And many things to many things? Nearly impossible, without an API layer sitting in between. It used to be that small businesses would only be able to accept payments by setting up merchant accounts with a bank or payment processor. If a customer from, say, Malaysia wanted to purchase a product, that customer data would get sent to an acquiring bank, through a card network, into the issuing bank which can accept or reject and then send that data all the way back through in a PCI compliant way—where the money then got held for 1-2 days. This was a complex process, and inherently localised to wherever the core bulk of customers were based. Stripe made itself indispensable as it amalgamates the wildly fragmented universe of local banks and offers instant payments acceptance to the equally fragmented universe of SMBs. If everyone was integrating into the same couple of banks, they’d just build out those integrations themselves and save themselves the transactional costs, but the chaos on each side of the equation creates the perfect opportunity for an API layer.

Immediate ROI

Case study: Persona – identity verification API that promotes seamless customer onboarding and ongoing operations, as well as reducing fraud.

Another key factor of a good API-first company is delivering immediate ROI. Persona is a great example. Let’s say an online alcohol retailer needs to verify customer’s ages before allowing them to purchase. By utilising Persona’s APIs, they don’t need to build passport and driver’s licence image recognition software for each and every jurisdiction, or hire auditors. The retailer kicks the identification process over to Persona, who can give a red or green light almost immediately based on image recognition matched to their vast network of identity databases. Customers can complete their orders without waiting for a human-driven verification process, driving immediate revenue and ensuring that the company remains compliant with all local regulations.

Expanding its own market

Case study: Plaid – enabling all companies to build fintech solutions.

API-first businesses are designed to allow companies to focus on their core mission, and delegate non-core activities to the API. These non-core activities could be perceived as “niche”, however the best of the best turn what might be niche for some into a massive market in its own right. Those who passed on Plaid’s early rounds looked at the number of fintechs, and the average annual contract sizes, and discounted the market as too small. But early investors saw that every company could become a fintech, if Plaid could deliver on its promise. The best API-first companies expand their TAM by empowering companies to offer services that once would have taken them too long to develop, and not worth the cost.

First-mover advantage

Case study: Merge.dev – moving fast to become the leading unified API for HRIS (human resources information system).

Many successful API-first companies have all grown beyond their core offering of ‘just’ being the connecting tissue in their respective ecosystem. While crafting a catalogue of connectors to various systems presents its technical challenges, this undertaking can be replicated by other companies willing to allocate a similar or higher amount of resources to fixing the problem. Once a number of competing players in a certain space (banking APIs, payroll APIs, HRIS etc.) have emerged, differentiation may become limited in the core product over time, driving the need to offer additional services (software PLUS, as we call it in one of the next sections). Therefore, there’s a strong first-mover advantage for startups who move fast, as they are able to sign up the majority of the supply and demand, and build services that create lock-in with that user base over time, before others offer a core product that has the same depth of connectivity and reliability.

Enabling collaboration and innovation

Case study: Zapier – empowering non-technical users to automate across different systems.

While some API-first businesses purely focus on developers, others empower non-technical users to connect their tools to different systems and create entirely new use cases. Zapier is a good example, it abstracts away the technicalities of APIs and embraces a no-code approach to make its catalogue of connectors available to business users with little programming background. By allowing these users to build powerful no-code automation workflows, it enables a wider population of users to build on top of each other’s templates.

Mission critical but non-core

Case study: Finch API – offering essential payroll and HRIS integrations for customers building in HR tech, enabling speed-to-market and focus on the core.

API-first businesses often address the long-tail of tech integrations a company maintains that are critical to the product but considered by engineers as non-core. Examples are compensation and equity platforms such as Ravio, Pave and Carta. These products heavily rely on being able to integrate with HRIS systems. Simultaneously, R&D teams want to move fast and focus on building out their own platform. The underlying data streams are essential, but the management of a large, fragmented set of API connections, often with regular technical and documentation changes creates additional complexity. As a result, teams prefer to outsource to a dedicated third party that can ensure maintenance, performance and reliability. Finch API is one example of an API-first business offering HRIS and payroll connectivity to companies who are building use cases that consume or require data from such customer systems.

Software PLUS

Case study: Twilio – offers a communication API plus thousands of global carrier partnerships; digital engagement such as personalised omnichannel marketing tools among others and digital agility such as deliverability optimisation.

Realising that software companies were eating the world at a fast pace, with an increased need to seamlessly communicate with customers, Twilio’s initial product was an API for cloud-based phone calls. However, communication was never being built in-house. Twilio quickly went from a one-product company to a multi-product company, recognising that developers were able to adopt services and tools very quickly and inexpensively. For non-core services, most businesses look for integrated, all-in-one solutions. Using a single platform that can handle a plethora of tasks, rather than piecing together numerous services, is usually a game-changer. They get to pick a vendor they like and trust, and can continue growing with them, allowing for that vendor to handle an increasing amount of challenges for them.

Network effects

Case study: Checkr – automates and streamlines the process of conducting background checks on individuals, whether they are potential employees, contractors, or tenants.

Network effects in API-first companies are like a party that keeps getting better the more people join. When developers integrate APIs into their products, they foster a growing ecosystem that increases the value of the APIs. APIs can create industry-wide standards, cultivating a climate of trust that resonates with both  companies and end-users. As more data points are collected, customers get added value as the API becomes enriched in itself as patterns emerge. 

Using Checkr as an example; one of their apparent network effect advantages is the expansion of its user base. As more businesses use their API, it accumulates a richer dataset, learns from it, enabling continuous improvement of its screening services. So, if one person has been evaluated by Checkr it remains on the database and the incremental cost is reduced when they are searched a second time. Each additional search helps Checkr spot patterns and trends in the data. The power of Checkr’s API increases as it integrates with more hiring and screening systems across different industries. Over time, Checkr has set an industry standard further cementing their moat: a widely adopted, efficient API that saves its customers time and resources.

Important things to consider…

First, business model clarity

How a company monetises its APIs, whether it’s through transaction fees, subscription models, or a combination, a transparent revenue model is crucial. It’s not uncommon to see signs of commoditization for the first layer of the product, so it’s equally important to see a defensibility in the broader offering within the control and enrichment layers. Flexible pricing is also usually beneficial, allowing a company to offer options that cater to businesses of all sizes and allowing for smaller startups which are usually more API-savvy than incumbents, to grow with them into larger enterprises without encountering cost barriers.

Then, developer-centric approach

Developers are the primary users of APIs: winning them over, and ensuring they have a positive experience, is vital for API-first companies. Developers can also provide valuable feedback and insights, which can lead to new features, enhancements, and even entirely new use cases. A developer-centric approach can help foster a strong ecosystem around the APIs, including the development of third-party applications and services that complement the company’s offerings.

Last but not least, data ownership

The ownership of data processed by API-first companies can vary depending on the terms and agreements in place between the API-first company and its users or customers. Here, we’re not considering personal user data, but rather aggregated and derived data, which can play an important role in an API-first company’s development. This data often includes insights, trends, and statistics that can be valuable for improving the service or offering analytics to customers. Whether or not this type of data can be collected impact issues such as data privacy, security, and the ability to use it outside of the API-first company’s platform.

Key questions we believe successful API-first companies will need to figure out

• Where does true defensibility, and differentiation, come from? How difficult would it be to rip and replace the service?
• How well-defined are the use cases you’re addressing?
• What is the real secret sauce in the product – is it building integrations that otherwise would be expensive and take a lot of time to build or is it standardising data? Enriching data? Helping stakeholders with new use cases?
• How can you think intelligently about monetization and pricing – to maximise revenue, unlock growth opportunities and streamline operations?
• How much should we worry about customer concentration? In many scaled API-first businesses there is significant concentration (I.e. Twilio and Uber), which can also help both companies scale quickly alongside each other.

If you’re building in the space, we’d love to hear from you. Reach out to Markus, Maxine or Molly! 

Further reading material that we recommend:

Plaid: Finance’s Next Great Network

Packy McCormick: Not Boring

Climate Tech VC: Lessons from Plaid for a future energy unicorn

Nea: Merge – a Unified API Platform to Drive the Future of Integrations