Headless API

Software usually consists of two parts. One part manages the data and the rules, such as which products exist and what they cost. The other part is what you see on the screen: buttons, images, menus. A headless API delivers only the first part. “Headless” literally means “without a head,” and the missing head is precisely this visible interface. API stands for application programming interface: a fixed list of requests that one program is allowed to make to another program, along with the agreed responses for them. An online shop with a headless API therefore doesn’t respond with a finished web page, but with pure data such as “item 7231, price €49.90, 12 in stock.”

Why companies detach their interface

In the past, both parts were fused together. A shop system contained the database and the design of the page right along with it. As long as there were only desktop browsers, this worked fine. Today, people buy through the website, through a phone app, through voice assistants, and at terminals in the store. With a fused system, you would have to maintain the product data separately for each of these channels.

With a headless API, the data exists only once. Every channel queries the same interface and builds its own presentation from it. If the marketing department changes a price, it applies everywhere immediately. This saves work and prevents inconsistencies between the app and the website.

The second reason is speed. A design team can completely redesign the website without anyone touching the inventory management system. Conversely, the system behind it can be swapped out as long as the interface stays the same. This separation is called decoupling, and it is the actual core of the idea.

What happens between request and response

The process is always the same. A program sends a request to an address on the network, for example to /products/7231. The server looks up the data and sends it back. The response comes in a format called JSON, which is easy for machines to read and looks roughly like a structured list of terms and values.

What then happens with this data is decided solely by the requesting program. The phone app displays the price large and bold, the website places it next to a photo, the checkout display simply prints it out. The API knows nothing about this. That’s exactly what makes it headless.

A common misconception is that every API is automatically headless. The difference lies in completeness: with a true headless architecture, the entire product can be operated solely through the interface, without hidden functions that only the bundled interface can perform. The price for this is effort. Anyone working headless has to build the interface themselves, including search, login and shopping cart. For a small project, a ready-made all-in-one system is often the wiser choice.

From shop systems to AI models

The term is most commonly encountered in content management systems and online retail. A headless CMS manages the text and images of a news site without dictating what an article looks like. Providers like Contentful or Strapi work this way. In retail, Shopify and Commercetools offer corresponding interfaces that let brands build their own shopping experiences.

Most AI services are also headless at their core. OpenAI, Anthropic and Google do sell visible chat programs, but they earn a lot of money from pure access to the model. A company sends text and gets text back. Whether this becomes a customer chat, a translation feature or a search field is up to the customer to decide.

In business news, “headless” therefore often appears as a signal for a business model. Whoever sells interfaces earns per request and stays in the background for customers. This brings stable revenue but makes the brand less visible. Some providers run both in parallel: their own app for visibility, the API for revenue.