Forget API-first. Try being API-capable.

In a blog posted last week, the always-interesting Kin Lane drew attention to the fact that NASCAR has recently published some API documentation using SwaggerUI. One point to note about this is the fact that an organisation as big as NASCAR, that generates hundreds of millions of dollars in advertising revenue every year, is using an open source and (depending on who you ask) outdated method of documenting their APIs when they could have a much flasher, trendier API portal. This got me thinking - maybe NASCAR doesn't care that much about their APIs, and maybe that's OK.?

In the tech world, buzzwords come and go, but "API-first" broke through the noise many years ago and has stuck around since. The idea is straightforward: design your APIs before anything else, ensuring seamless integration and a developer-friendly experience. If you do this, and treat your APIs like first-class citizens, untold riches await. But what if your company isn't in a position to lead with APIs? Maybe you're entrenched in legacy systems, or perhaps the resources to overhaul your architecture just aren't there. Does that mean you should throw in the towel? Not at all. Instead of aiming to be API-first, consider becoming simply API-capable.

Before diving into the alternative, let's take a stab at defining API-first. An API-first approach means prioritizing the design and development of APIs before other components of a software project. This strategy emphasizes collaboration, scalability, and adaptability, making it easier for developers to work together and create robust applications. However, this approach often requires a significant shift in development processes and a substantial investment in redesigning existing systems.

For many businesses, especially those with established infrastructures, transitioning to an API-first model can be daunting. This is where being API-capable comes into play. Instead of a complete overhaul, focus on integrating APIs into your current systems to enhance functionality and interoperability. This could mean generating API documentation from an existing service, or retrofitting a RESTful API on top of a legacy system. It might even mean just doing an API audit and figuring out how many APIs you actually have. This approach allows you to reap the benefits of APIs without the need for a ground-up redesign.

Being API-first was essential for companies like Stripe, Twilio and Plaid. APIs are their core products. But if you're a retail bank, an insurance company, an airline, or a car manufacturer, you likely have different priorities. Becoming API-capable isn't about pivoting your entire business model to pay-per-usage APIs; it's about staying competitive, making it easier for your partner network to integrate with your systems, and unlocking new revenue streams that aren't going to disrupt your traditional business model. For these companies, to paraphrase Kin, APIs are a lucrative side-hustle rather than a full-time career.?

While the tech hype cycle has moved on to the impact that AI agents will have on web APIs, the majority of large organisations are still tackling the move from SOAP to REST. In my experience, there's usually a big gap between the topics that are grabbing headlines and what's actually happening inside the four walls of most companies, especially if they aren't primarily software companies.?

By becoming API-capable, a business can enhance its current systems, improve interoperability, and position itself for future growth. It's about making thoughtful, strategic decisions that align with your company's unique needs and capabilities; you can worry about AI agents in a year or two.?