---
type: "article"
title: "Everybody Wants to Have an API Product"
summary: "API-as-a-Product is a journey and not the final destination."
newsletter: "The API Changelog"
newsletter_handle: "apichangelog"
newsletter_url: "https://usecommune.com/n/apichangelog"
author: "Bruno Pedro (@bpedro)"
published: "2026-01-07T16:29:48.000Z"
canonical_url: "https://usecommune.com/n/apichangelog/a/everybody-wants-to-have-an-api-product"
markdown_url: "https://usecommune.com/n/apichangelog/a/everybody-wants-to-have-an-api-product.md"
chat_url: "https://usecommune.com/n/apichangelog/a/everybody-wants-to-have-an-api-product/chat"
source_url: "https://apichangelog.substack.com/p/everybody-wants-to-have-an-api-product"
body_source: "imported"
likes: 0
replies: 0
body_words: 2494
---

# Everybody Wants to Have an API Product

Building API products is a complex thing. "It's not easy, and it can't be done using a tool," shared Daniel Kocot, a highly experienced software architect and API designer. During a conversation we had in December 2025, Kocot and I touched on important topics such as the kind of logic you can put into a gateway, the four data interface quadrants, and how to identify API capabilities. In the end, Kocot shared, everybody wants to have an API product. So, sit back and listen to the full recorded interview. Or, if you prefer, go through the full transcript below.

***

> This article is brought to you with the help of our supporter, [Scalar](https://scalar.com/).
>
> **[Scalar](https://scalar.com/)** is the modern OpenAPI platform for the entire API lifecycle. Govern APIs with Scalar Registry, test offline with their built-in Client, generate beautiful documentation, and ship SDKs instantly - all from your single source of truth.

***

The “Behind the APIs” interview series is a collaboration between Scalar and the API Changelog newsletter.

Here’s the transcript of the “Behind the APIs” session with Daniel Kocot. Parts of the transcript have been edited for improved readability.

**Bruno Pedro:** Hello. I’m Bruno Pedro, and we’re here at the apidays conference running the Scalar collaboration with the API Changelog newsletter called “Behind the APIs.” Today I have here with me Daniel Kocot. Daniel is one of the AsyncAPI ambassadors, and he has more than a decade of experience in API design and also software architecture. So he brings a lot of experience and a lot of knowledge to the table. Hello Daniel. How are you?

**Daniel Kocot:** Hello, Bruno. Thanks for having me. So, yeah, I’m part of the AsyncAPI community and part of other communities, but this is my role on this apidays so far. So, I’m part of the ambassador program, yeah.

**BP:** Nice, nice, nice. I know that one of the topics you’re very passionate about has to do with API gateways. And it’s something that many, many people like to talk about, and I’m sure they have a lot of questions and I think one of the questions that a lot of people would like to ask you is “What do you think about having business logic inside an API gateway?”

**DK:** Yeah, it’s actually part of my whole API life stories there. So, it started actually in 2018, being in a partnership with Kong and starting it up in Germany. So, we were the first really looking at this and Kong was the rising star at that point. Nowadays, we have even more gateways available and even proxies, and so on. And yeah, it’s still a fact. So, what we see is actually, I even did it in my talk today, or even talked in my talk today about the gateway becoming the next ESB[1](#footnote-1). So, in a second version or third version. So, people putting all the logic that’s actually part of, or just needed for the API to make it quite simple, and then we have everything in the gateway. So, we know that gateways have the possibility of using plugins and extensions, or whatever it is actually called. But the question is, “Is this really needed?” Is it needed, or do I just have the need for a barrier so that it’s just protected and the effects come later, or this how we can really handle this?

**BP:** Right, right. Good point, good point. But in your opinion, is there any type of logic at all that you can add, or that it’s good to have inside the gateway at all?

**DK:** Actually, the simple stuff. So when I do a simple transformation from JSON to XML or XML to JSON, this can be actually part of the gateway because it’s not real business logic. But when I really have the logic in regards of security authorization or anything like that, it shouldn’t be part of the gateway that the gateway has to decide who is actually capable of using the API. So it’s really not displaced there, so it should be more related to after the gateway or maybe with some help from an IdP[2](#footnote-2) or something like that, not directly in the gateway handler, there.

**BP:** Right. Right. Okay. So, all that other logic that does not sit inside the gateway. I know that one of the terms you use for that is API capability, right? So, can you tell us a little bit more about what you think about API capabilities?

**DK:** Yeah, I can do that. We worked in a lot of projects in very big enterprises. So we hit always the stage with enterprise architects, and they are actually not on the level to really see the technology side. We hear a lot of times the terms of middleware, so really the old days are coming back there, or still there. And when I think about enterprise architecture is always about capabilities, what I want to have actually for the business to be provided and not so deeply on the technology side. So this is actually where the term comes from, so that there is no new thing. It’s really the capability what the business wants to achieve, and for us, it’s the starting point to really go from that and then go more on the technical level and going there actually, yeah.

**BP:** So, you always start by first understanding the needs of the business, and only after you have a full understanding of that you try to translate it into actual implementation or more technically oriented documentation.

**DK:** Yeah. In the end, we use the APIOps cycles methodology for that so it’s really filling out canvases that even are capable for non-technical people to understand what they actually want to achieve or what the consumer side wants to have from us to really learn from each other and see, okay, this is what is needed. Or this is something we can provide, or this is something we cannot provide and we need third parties or any anybody else involved. So really learning from the perspective of non-technical people, not really going into “Ah yeah, they said they want this so they want to have a REST API.” And then we are in technology and you know what happens then? The rubbish starts and we end in the technology disaster or chaos in big parts, so.

**BP:** Mhm. Yeah. And that’s a very interesting point, you know, let’s say the style of the API or you know, what the API exposes and so on. I know that you you are also one of the co-author of a framework for identifying, the type of API and where an API sits, with respect to what it provides or what it exposes. It has to do with quadrants. Can you share more about that?

**DK:** Yeah, I can go into that. So we developed the so-called data interface quadrants because we saw in projects that we are not really capable in being measurable saying okay… The story behind is actually totally easy to explain. We had some kind of project to deal with so-called core APIs. So really raw data APIs. And at the end of the project, one stakeholder asked us, "What do you have achieved?" and we said, yeah, we have 120 APIs developed over one year with the things we build up here and he was like, "Oh yeah, that's nice." And then we thought, "What was actually the goal?" Oh, the goal was to have more data-related product APIs, and we looked at the APIs and said, "Okay, they are not data products." So we really had more use case specific ones and was really like to say okay, we need some kind of measurement for that, and there was nothing at that point, so we were not really aware of anything.

[![](https://substackcdn.com/image/fetch/$s_!lNav!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2d2d8951-1adc-4ec9-a76c-69a3878092ef_877x858.png)](https://substackcdn.com/image/fetch/$s_!lNav!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2d2d8951-1adc-4ec9-a76c-69a3878092ef_877x858.png)

*This Data Interface Quadrants diagram was adapted from the “[Introducing Data Interface Quadrants (DIQs)](https://www.codecentric.de/en/knowledge-hub/blog/introducing-data-interface-quadrants-diqs)” article by Daniel Kocot and Miriam Greis.*

And this was the start of the data interface quadrants and the more you talk with people you more do projects in this direction, you more get into this quadrant that you have the four quadrants going into the discussion saying okay do we have data APIs, do we have somehow more related APIs to developers bringing frontends to the top so the backend-for-frontend[3](#footnote-3) style or do you really have data products where everybody is dreaming of in the end that can be reusable on the side of APIs and actually and then we have the composed ones that we really build on purpose but we build them for be reusable in the whole organization not for just the tiny part we are actually now in so really reusable in the whole organization. And that's the thing behind the data interface quadrants to really make this, I would say, visible, measurable, to really make clear, okay, in which direction we go, and we use it now directly from the start, saying, okay, what is actually the purpose of your API? Where do you want to go with this idea of having the API? Okay, you want to have a data-related API but just internally in your bounded context, then you can do this, and you don't have to be afraid of putting so many things directly upfront, but you should build it with the next step in mind. So this is also something a lot of people then really reflect on and spend time directly from the beginning in building these data product APIs.

**BP:** Interesting, interesting. So, as far as I understand so on the left-hand side of the diagram we you have all the data-oriented types of APIs, and on the right-hand side, you have those types of APIs that somehow expose something else that is not just mirroring the data model itself. And can you call those things that are exposed by those APIs, for example, composition services, can we call those things the capabilities? Or are they something else?

**DK:** Yeah, capabilities are actually the stuff in the upper corner. So when we talk about it, data product platform things there. So this API is more data-related. Really related to the data set, not really, yeah little bit aggregated, but not that far aggregated, but being able to be reused by people. And then we have the real use case stuff so that we really can see on the other side, this is the stuff that can be reused. It’s really well prepared, so it’s already in production with others, and I can really use the stuff and don’t have to think about, okay, I have to build something on my own, which then I take these two data product-related APIs and build my composed one, now that this is already ready to be used by others then.

**BP:** Interesting. Interesting. Yeah. From what you’ve been seeing from your experience, what is the quadrant where most people build their APIs in? So are you seeing more composition services, backend-for-frontends, data APIs, or a mix of everything?

**DK:** Yeah, it’s difficult. So, what we see most of the time is that we’re still in the lower quadrants. Everybody wants to have an API-as-a-Product, but you know it yourself, it’s hard actually to get there and convince people because we are in this business, and it has to be fast. And if I start really it’s hard to really move fully into this as-a-product type of thing. So most of what we see is somehow hitting the upper stuff, but most of the things are really on the ground level, and then people are really, yeah, disappointed because they say ah, nobody’s using our stuff yeah because it’s maybe not good described, it’s not really well prepared to be reused, and so on and so on. So again, this is then a journey, and the data interface quadrants will help guide you on that journey and see, okay, yeah, I’m more here, but I want to go there. What I have to do and this is then type of yeah consulting we do with customers to really get to move up on the next axis to really say okay I want to be reusable, I want to be more composition orientated then I have to do this and build everything around that and then the whole story gets this round thing and it really is present in what I want to have achieved actually.

**BP:** So the ones that are, let’s say, on the upper quadrants are those that are more prepared to be consumed by external entities, for instance.

**DK:** Yeah. And it’s always a definition of who is external. So it could be even inside a company, another department could even also be external because they are not in the bounded context when we go into the domain-driven area and take this description and say okay, they are not in our context, they don’t know what we are actually dealing with, but they want to have our data. So we prepare everything specialized, and when people understand this, it’s an easy move to get from the lower level to the upper level, but it could also happen that you go from the upper level to the lower level because you missed something there. So in the end, it’s a complex thing. So, it’s not easy. It cannot be done by using a tool. It’s really learning and really adapting what you see and maybe listen to people at conferences like apidays, and take something with you, and then say, “Okay, I heard this. I cannot do this right now, but I’m on a track or on a way to really move in this direction.” I think this is the main important thing that people need to understand, not that they have to achieve something, but that they make themselves on a good way to be able to achieve this, yeah.

**BP:** Right, right, right. And I think many people and many companies are on their way to trying to achieve that. Thanks for sharing those very insightful thoughts. As you could see, Daniel’s experience in API design and also architecture show in the way that he answered all the questions, so thank you, Daniel.

**DK:** You’re welcome. Bye.

***

[1](#footnote-anchor-1)

Enterprise Service Bus, or ESB, is a centralized integration layer that connects disparate systems by routing, transforming, and orchestrating messages so applications can communicate without being tightly coupled.

[2](#footnote-anchor-2)

Identity Provider, or IdP, is a system that verifies user identities and issues authentication credentials so other applications can trust who a user is.

[3](#footnote-anchor-3)

Backend-for-frontend, or BFF, is a dedicated backend service tailored to the needs of a specific client (such as a Web or mobile app), exposing only the data and operations that the client requires.

***

## Discussion

No replies yet.