A C-Level Introduction to API Composition - WunderGraph

Björn Schwenzer

COO & Co-Founder at WunderGraph

November 20, 2023·11min read

Last updated on September 9, 2025

State of GraphQL Federation 2026

As the number of APIs keeps growing and headless services are on the rise, understanding APIs and API Composition has become a necessity for decision makers in almost any industry. The impact of every device, production plant, product usage and sales process being connected to the internet and generating an ever increasing stream of data is so profound that understanding the basic paradigms is critical to making the right strategic decisions.

Disclaimer: this text is intended for people with business focus and limited technical knowledge.

Introduction to APIs: how software talks to each other

APIs, or Application Programming Interfaces, are dedicated data interchange points that link different software applications together. This can be the case on a local computer, but also on different devices thousands of miles apart, all connected over the internet. A perfect example is in your hands every day: your smartphone, retrieving emails from a mail server, or displaying the local weather as provided by a weather service.

APIs allow applications to exchange data and invoke functions from each other to perform a certain task, such as “provide the weather for my location”. From an API perspective, your smartphone app would send a request containing your location to the weather service, which would then retrieve the weather parameters based on the given location and return it back to your app. All API conversations follow this “request and response” pattern.

So at their core, APIs enable connectivity, allowing various software components to interact, even when they're built using different programming languages or run on different platforms. It also means that software no longer needs to contain all the logic itself (hence called a software “monolith”), but utilize a variety of services to perform specific tasks. This is called a service-based architecture.

APIs commoditize services

The benefit from a software developer’s point of view is obvious: rather than having to build everything yourself, which takes time and costs money and is equal to reinventing the wheel, you can simply focus on the added value of your software and connect external services which solve specific needs. This includes standard building blocks of software, such as authentication. And vice versa, if you build your application to include specific APIs, you can provide your service to others which invoke it through the interface.

It’s the digital representation of globalization and distributed supply chains: OEMs, like car manufacturers, usually buy many components from suppliers and then integrate them into their product, which reduces their level of vertical integration, especially in areas they have no expertise in, for example in manufacturing display screens or tyres for their cars.

This example also clearly shows the need for one key strategic decision: where to integrate vertically and “own the stack”, and where to rely on suppliers (service providers). We will come back to this later.

One challenge with APIs is that they come in many types and shapes, also because their design has evolved over the years. Many modern APIs follow a standardized format, which is called a schema. This is like a standardized manual of how to work with, and what to expect from an API. But there are other types of APIs and protocols which govern exactly how the data is exchanged over the network. Also, security and stability are relevant factors and highly depend on how well APIs have been implemented.

This leads to a lot of work when developers are integrating APIs. The time needed for this as well as the risks involved when doing things manually, such as security flaws or performance issues, are the main reasons why API integration and management needs to be automated. This is especially relevant as the number of APIs to be managed keeps growing, and their data becomes a critical element of decision making. Essentially, it’s the reason why we founded WunderGraph.

API Composition: building individual service stacks

Whereas API integration describes a process or technical task, API Composition is a paradigm that stands for the creation of added value by integrating certain services, functionality and data by means of their respective APIs to form a new service or product. The result is called a “service stack”.

This paradigm is closely related to the ascent of “headless architecture”. If you can build service stacks to form a new application, you can also de-couple all front-ends from their services to make them even more versatile and light-weight. The front-end is the so-called user interface, or “UI”, to interact with the actual service, accepting user inputs and visualizing the outputs (yes, a screen and keyboard also are a kind of interface :). Previously, every full-fledged application usually came with a front-end, but under the API Composition paradigm it’s only the functionality that matters, not the UI.

API Composition thus allows you to build your personalized service stack for your company and then add one seamless UI on top. Any specific functionality that you require can be added at different levels, depending on your needs. For example, your stack could consist of:

Of course, to make all this work, you need a “composer” like WunderGraph Cosmo for your API symphony of services in your stack. This piece of software is the facilitator required to bind your stack together, make it usable as one, add observability and connect your front-end and custom software.

API integration refers to the task of connecting APIs. API composition is building a stack of (mostly) headless services by connecting to their APIs to create a new service, product or entire ecosystem.

API Composition is not just a technological strategy, it’s a business strategy

As you can see, API Composition is not just relevant if you are building software - it’s relevant to any business as we all depend on a host of tools and services to run our companies. It also makes a great difference to consumers of your services, in the most basic version as part of your ecommerce offering. API Composition allows you to present a seamless user experience across multiple systems, such as payments, shop, and content, where users would otherwise notice gaps or disruptions when following their customer journey.

If APIs are the building blocks of digital transformation, enabling different software services to connect and collaborate, API Composition is the strategy to leverage these building blocks to create sophisticated digital products with an excellent customer experience. At the end of the day, this will be the differentiating factor to stay ahead of the curve in innovation, growth and market share in the ever-evolving digital landscape.

API first and the MACH paradigm

What you have learned so far are key cornerstones of the so-called MACH paradigm. This acronym stands for:

If you will, it’s the “meta stack” that describes how a lot of modern software products will be composed: you take some micro services that you’ve built API-first, and run them on a cloud-based system in a headless way for maximum flexibility.

So what is a micro service, and what does API first mean?

A micro service is the opposite of a software monolith. The picture in your mind straight out of the “2001 - A Space Odyssey” movie isn’t too far off here: essentially, in the past software has been built as one large chunk of code (I’m simplifying, but you get the idea).

The downside of this is that at some point, monoliths become unmanageable. If changes need to be made which touch core functionality, the cascade of side effects this may trigger - from interfaces/APIs to databases to error handling etc. - can saturate entire development teams for months, and even if they manage to stay on top of things, the monolith becomes a big bloated patchwork code block over time and has to be completely rewritten at some point (I’ve been there a few times; your CFO doesn’t like this).

With the rise of agile software development, it became obvious to even to the most convicted monolithians that a monolith is a thing of the past, and modern software development calls for more flexibility and smaller increments; not just in development, but also in output. Enter micro services.

“Micro” may be misleading, but it means that software is written as smaller programs which ideally perform very specific tasks - or “services”, for example signing on a user or rendering output for the website. These micro services all offer an API for connectivity to all other services, for example by means of an API gateway or any kind of message system that facilitates data exchange between the micro services.

As micro services grow, so does the number of APIs and the need to orchestrate this data exchange. Also, it now makes a lot of sense to not start with coding the service, but with defining the API.

This is a fundamental paradigm shift as most of the time, engineers will write the software and then think about data exchange, which holds a lot of challenges. It’s a little bit like the “design follows function” or “function follows design” dichotomy. If you truly want to build services that are interchangeable and interconnectable, you have to start with defining the API, which in turn defines what engineers need to develop.

By building micro services API-first, software systems become super flexible, easier to maintain, to document, to exchange, and faster to develop as you can split work naturally between teams - their window to the outside world is the API; that’s all they need to know.

The Strategic Value of understanding APIs, API Composition and MACH

So how do these rather technical things translate into something that’s relevant to you as an executive? After all, you have experienced experts taking care of this, so why bother?

Like a captain on the bridge, you still need to understand how a ship is steered even though you’re not the sailor at the helm. This cannot (and should not) be delegated.

Let’s look at four strategically relevant aspects in particular:

1. Better decision making

Any decision you make should be based on data–the more (instantly available) data you have, the more complete your understanding of the situation, and the more likely it is that you know more than your competitors. The way to obtain the data is through APIs, so it will be in your best interest to create as many API endpoints as you possibly can to generate that data.

Do you remember all the occasions when you asked people to provide a dashboard of certain data, but you got back a manually groomed Excel spreadsheet? You should encourage your entire organization to think “API first”: which data will be exchanged? Which data would you like to collect (within legal boundaries, of course)? By fostering this way of thinking, you will establish a mindset in your company that makes sure you get the most information out of any process or system you connect to. From my own experience, I know that people often focus on features first, and APIs or data generation comes in last when all design decisions have been made and deadlines have been agreed upon. Make sure the whole API complex is made a priority, everywhere, and don’t cut people short when API work adds to the timeline. It’s worth it, and you have to show that you care on the executive level.

2. Faster time-to-market

By taking a modular approach, your teams will be able to ship and iterate faster, which gives you - thanks to the data at hand - better reaction times to optimize. Make sure to not go for monolithic approaches. If a project to introduce new capabilities takes longer than a few months to even ship a prototype, challenge the team if they are indeed following an API-first strategy, or if they might be affected by the not invented here syndrome.

3. Stack flexibility: services become interchangeable

Another advantage to understand is that you become less dependent on vendors of standard functionality. If you follow a composed stack, you gain the freedom of exchanging parts of it without having to rebuild the entire construct. Not happy with a service that you integrated? Replace it! Want to add more functionality? Add it!

The reason is that everything is abstracted by APIs, and your service composer such as the WunderGraph platform will be able to connect to different services easily. Of course, it’s also important that the composer is able to work with any services and is not limited in any way.

4. Business opportunity

Should you be developing your own software, you may want to do it in a headless, or at least API-first way to make it a business model. Your product could become a building block of someone else’s stack, or - if not used externally - of some new product that you are building in house. In order for this to be possible, you need to make sure it’s designed that way right from the beginning, making it a core strategy.

Risks and Challenges

Make no mistake: API Composition is no free ride to success. If you recall the automaker’s OEM example and consider the recent disruptions of global supply chains, it’s clear that each dependency adds its own risk to the stack. You need to decide carefully which parts of the stack you want to (or must) own in order to de-risk your operations.

A good differentiator here would be how much choice you have to delegate a specific service you’ll need. The more options you have, the better, and the less likely you will suffer from disruptions at the chosen supplier. An API Composition platform like WunderGraph Cosmo will make sure that you can quickly replace any service that becomes a liability or falls short of expectations.

Another challenge is security. Interfaces need to be safeguarded, and it’s important to have a solution in place that delivers this out of the box when connecting all your APIs. Ideally, security is built-in “by design”.

Then, there is performance. At WunderGraph, we have made it our priority to build the fastest API Composition platform on the market, but even we can’t control how fast each individual service responds.

The Future of API Composition

As we look ahead, it's clear that API Composition will play a crucial role in shaping the technological landscape. Megatrends like artificial intelligence (AI), machine learning (ML), and the Internet of Things (IoT), all depending heavily on API connectivity to exchange data, will further drive the adoption of the API Composition paradigm.