API startups are hot. With the rise of Twilio, the near-acquisition of Plaid, and the surge of recent startups in the space, it’s clear that tomorrow’s tech companies will be powered by external APIs, each responsible for outsourcing a different piece of infrastructure.
In this piece, Gil Feig (Co-Founder atMerge) and Julianna Lamb (Co-Founder atStytch) discuss some of the most important trends seen across rising players in the API space.
Innovation is rampant as API startups emerge at growing rates. Quality has soared across documentation, implementation, design, visibility, insights, and more. But APIs, like web applications, have a frontend. This may come in the form of JSON or XML, but it’s a view that is consumed by a paying customer. It wasn’t until recently that trailblazers like Stripe took this front-end seriously, and made APIs cool. But what exactly is a cool API?
A cool API is built with the user in mind. Data structures, endpoints, and documentation are all designed with the same rigorous attention typically directed towards the slick-looking landing page that first draws in customers. The cool API knows it's not just selling to product managers who desire time and cost savings, but also to engineers who are increasingly responsible for vendor decisions and, obviously, implementation. And while companies may rise and fall, both PMs and engineers have the option of introducing your product to their future employers— or not. We believe a critical factor in an APIs longevity is, then, its coolness. Think of it like making that all important first-impression at a party.
Merge is a leading provider of Human Resource (HRIS), Payroll and Recruiting (ATS) integrations for B2B companies. Companies that integrate once with Merge’s API automatically offer integrations with 30+ platforms to their customers. Stytch makes it simple to seamlessly onboard, authenticate, and engage your users with passwordless authentication and user management APIs and SDKs.
Despite evolving separately and solving different problems, we found that both companies developed similarities in company culture, product, and implementation.
API First
Early on, Merge and Stytch recognized that we weren’t just building products and then exposing them with APIs. The APIs were our products. To us, this represents a radical shift in how API start-ups operate.
What differentiates this new wave of API startups is the freedom to build APIs the way we want. Systems born in the on-prem and early-cloud era lacked, up until a few years ago, the plasticity to create a modern API. These APIs were built from the backend up, and so are often limited by the implementation details of the systems they expose.
We have the privilege of starting companies in an era where the API is first documented and implemented before the underlying systems are created. This ordering is crucial to provide design flexibility for our core product: the API. Our APIs are built to power experiences and flows within other products, and this design flexibility allows the use cases of our customers to be thoroughly accounted for. Through iterative customer collaboration, we’ve achieved easy to add, fully native experiences. We’ve aspired to make our APIs cool.
API = A Pretty Interface
Design holds a double meaning for Merge and Stytch. Our products are APIs, and so we scrutinize every field, endpoint, and available action to cater towards a robust user-developer experience. At the same time, we recognize the value of and invest heavily in “traditional” product design. Whether it’s landing pages, documentation, embeddable UI components, or dashboards we constantly ask how to better craft pages that express complex topics within a simple UI.
There has been a recent wave of fantastic startups that help to design API documentation, however at both Merge and Stytch there was a clear decision to build our own. We needed flexibility to express concepts, create guides, and provide interactive experiences for our users. Though we each followed a different path to accomplish this, we couldn’t be more thrilled with the other’s result.
At Stytch, we designed and built our documentation in-house. All documentation lives in a Github repo like the rest of our code, so it’s become a natural part of the development process to include documentation changes when new code is shipped. In our early days we initially tested documentation through OpenAPI. However, we became continually frustrated with the time it took to implement OpenAPI's auto-generation with our own product. We realized that not only would it be more efficient to build our own client libraries, but by doing so we would gain a far deeper understanding of how our documentation actually worked. We found that making documentation changes as a standalone changeset, separate from the implementation of API endpoints, allowed for more detailed and flexible documentation. The downside of this DIY method is that some work required to make sure that the API, client libraries, and documentation are in-sync.
Merge chose to generate documentation using OpenAPI. Acknowledging that the ecosystem is young, we saw it as an opportunity to provide feedback and take part in an audacious open-source initiative. While the specification’s imperfections imposed a burden, we ultimately realized time-saving automation: changing an API endpoint automatically regenerates documentation, deploys the frontend, regenerates SDKs, and merges the code. When the backend receives new API functionality, we create generic methods that automatically generate pixel-perfect interactive experiences for the frontend.
Companies who use API products are able to build their core product faster. In our expanding API-economy we’ll continue to see more and more capabilities packaged in APIs. The difference, we believe, between losers and winners lies in who creates an API that’s cool— not just functional. Merge and Stytch are inspired to help craft new standards for the next generation of API companies.
Check out Merge here: https://merge.dev
Check out Stytch here: https://stytch.com/
Share
