What is an API-first approach in practice? - digitalML

What is an API-First Approach in Practice? [Digital: Disrupted Podcast Episode]

API Strategy

What is an API-First Approach in Practice?

·  5 Min Read

In July 2022, digitalML’s John Bogard appeared as a guest on the Digital: Disrupted podcast, hosted by Paul Muller and sponsored by Rocket Software. The episode, which focuses on Making your Business Programmable using an API-first approach is now unfortunately unavailable to stream, but we wanted to capture some of the key questions in this post. What does API-first actually mean? What are some examples of API-first companies and are they seeing success? What are the advantages and disadvantages? And what’s the secret sauce to API-first at scale?

What does API-first mean? What is an API-first approach?

API-first means treating application programming interfaces (APIs) as first-class artifacts and a strategic business asset, with reusability and composability key considerations. An API-first approach leverages a combination of business and technical strategy to deliver product-centric APIs, instead of APIs as by-products of a project approach to development. This in turn delivers better time- and volume to market of differentiated digital products and services. True API-first is business-led and collaborative.

Is API-first the same as API design-first?

We sometimes hear API-first and API design-first used interchangeably as concepts, but there are differences! API-first is the overarching strategy and approach. API design-first is a particular tactic to help organizations get there. It means designing an API outside-in, often tied to a business-priorities-focused planning stage. API design-first is key for developing composable, consistent, and secure APIs that represent your business capabilities.

What are some examples of API-first companies? Are they seeing success?

API-first companies are making their core functionality available as composable, consistent, and reliable APIs. Think of business capabilities like travel booking, pharmacy benefits, and payments, and how customers want to consume these capabilities at scale. In the podcast episode, John explains that we’re seeing very interesting approaches to API-first:

  • From new (API-first-native) companies like Twilio, offering messaging and communication via an API which can be stand-alone or embedded into other applications e.g. Uber to help drivers communicate with their riders.
  • From hybrid companies like FinTechs that are offering digital functionality like payments or international money transfer but have to integrate with legacy back-ends and payment rails.
  • From incumbent enterprises that are racing to expose existing functionality as an API (or Event, Message, Microservice etc.) but have additional digital complexity that comes with their existing landscape. We work closely with enterprises like these, and understand that the goal state is composable business capabilities reliably exposed as APIs (or whatever format is needed), leveraged by cross-functional teams of business and IT users to support new offerings across all channels.

There’s tangible evidence that API-first is working too. The top 10 API-first companies and products (think Amazon Web Services, Google Cloud, Stripe, Twilio etc.) have a combined valuation of $1.56 trillion. Open banking is predicted to reach $3.6 trillion market share in the next 8 years. And 83% of all web traffic now comes from some sort of API.

Advantages and challenges of being an API-first company?

Next, John and Paul discussed the advantages and challenges of becoming API-first.


  1. Happy customers! API-first enables better digital products and services that meet changing needs and can be offered wherever the customer is. Organizations can also expect better speed to market and safe changes and iteration for their offerings.
  2. And happy internal talent! API-first can also help enable collaboration between business and IT. John shared a great example of Coinbase’s CEO Brian Armstrong recently declaring that they’re encouraging communication through APIs instead of endless meetings. While product leaders can operate independently, there are often common elements across products, and API-first ensure these can be shared to improve operational efficiency and unlock innovation
  3. The fly-wheel effect of composability. The more composable building blocks that are being developed through an API-first approach, providing coverage of your core business capabilities, the more:
    1. responsiveness and faster time to market you get,
    2. digital disruption you can drive,
    3. revenue and innovation and customer satisfaction that happens.
  4. Reduced dependencies on platforms and vendors. Done correctly, organizations can do API-first in an abstracted way, so they’re investing in their functionality rather than the implementation of it and therefore not tightly coupled to platforms or vendors.



  1. Digital complexity. Especially for large enterprises, there’s complexity lurking that can make API-first at scale challenging. This can include provider and consumer relationships and dependencies, reliance on internal and 3rd party systems, ongoing changes in the APIs themselves plus priority and partnership changes etc.
  2. Technical and business talent are hard to find. API-first needs both to work, and in the age of the great resignation, developers are hard to come by, as are business folk who understand the API space. As Paul mentioned in the episode, APIs have traditionally been thought of as purely an IT issue. But thankfully that’s beginning to change and the business are buying into API-first – here’s a great anecdote from 10x Banking’s Joel Reich on his journey into APIs.
  3. It’s difficult to design-well and offer a good consistent experience when the data and business logic that is coded as part of implementation comes from a complex IT landscape.
  4. Legacy and technical debt. Customers are always going to want more – and this is a good thing for API-first, but we can’t expect customers to wait 9 months for more. We’ve seen one enterprise with 28 CRM systems that have to be mapped together to get a customer account validation API. And another with a claims management system that provides claims information but has its logic built into a monolithic application. This makes it challenging to move with the speed needed for API-first to work at scale.

So how can companies trying to adopt API-first move more quickly to gain these advantages and overcome the challenges? Here are 3 best practices we’re seeing enterprises have success with.

Secret Sauce: API-first Best Practices

1. A Holistic Catalog

Right across the API-first maturity journey, organizations need an accurate view of:

  • What APIs they already have
  • How these APIs are aligned to the business capability model – what’s your coverage and gaps
  • What’s “good” (aka complete, consistent, and compliant) and what’s not
    • And how to remedy that
  • Which existing APIs could be promoted for reuse across the organization

A catalog is the answer, specifically an advanced one like our ignite holistic catalog which can capture all types of APIs across their lifecycles into a live and active source of truth, in views that are useable by both business and IT stakeholders. This helps organizations encourage the composability and reuse aspects of API-first, as well as tracking where they are now as well as where are at each step of the way in their journey.

2. API Lifecycle Management and Governance

For APIs to be consumable and reusable, they need to be designed and built properly. API lifecycle management (that’s focused on creating a well-defined yet flexible process for the design to deploy stages of API development) helps organizations ensure quality and consistency for API-first at scale. Our ignite Platform focuses on exactly that, while streamlining the complexities across the lifecycle that large enterprises face

And, as we heard on the podcast, while API governance has historically been thought of as a 4-letter word, done right it’s transparent, easy and empowering. John mentions accountability as his first thought on governance in the show’s lightning question round, and done in a configurable and automated way, governance helps support the value of the functionality being exposed as APIs; it’s predictable and reliable. More on maturing API governance in a recent blog.

3. Business and IT Collaboration

Focusing on business and IT collaboration across the development lifecycle is key for unlocking some key areas of API-first at scale too:

  • Role and persona enablement for collaborative innovation that leverages expertise across the enterprise to deliver differentiated customer experiences. Abstracted and technical views (like Designs and Specifications in ignite) of APIs and automation of manual tasks in the lifecycle can help with this.
  • Build out of an enterprise planning and prioritization muscle that helps drive API as a product. Understanding business capabilities, taxonomy attributes (e.g. customer, accounts, advisor, and the API assets supporting these in a way that incorporates business and IT roles is the first step to building that muscle and process.

These three best practices are the secret sauce to an API-first approach that works at scale, especially in large enterprises.



About the Author

Learn the Best API Practices and Get the Latest ignite Updates

What can we help you find?

Use of cookies

We use cookies to make the website optimal and to continuously improve it. By continuing to use the site, you consent to the use of cookies. Please refer to the privacy policy for more information.