Who Certifies The APIs Your Agents Are Calling?

Speaker A: Hi everyone. Welcome to the API Governance for Skill podcast. My name is Ikenna. Uh, Ikenna, I'm your host on this pod. Uh, and today I'm delighted to have Nicholas and Samuel from Happy Hope here with me.

Speaker B: Hi.

Speaker C: On the show.

Speaker A: How are you guys?

Speaker D: Very well, thank you, thank you, thank

Speaker B: you for the invitation again. A, uh, pleasure.

Speaker A: Yeah, it's, it's good, it's great to have you both here. It's just been great to watch, you know, the great work you guys do at, at Happy Hub. And I hope today you'll be able to just give a, uh, give our listeners an intro into what you do. But you know, I do follow you guys. I know your kind of open source contributions. I've played with your voiding API client a bit and this is great. You know, it's been great. You know, I also follow some of your blog posts. Samuel, great blog post you write for, uh, our listeners. Can you just start by telling us maybe a bit about yourselves and uh, a bit about Happy Hope. For those who don't know Happy Hope,

Speaker B: I can start and I can tell you that it's my first kind of this kind of podcast appearance. Samuel has a bit more experience, so that's why, that's why I amassing a bit of your patience in case I uh, do any mistakes or I cannot keep up. So thank you very much for the invitation, Ikenna. So I'm, um, Nicolas. I live. So the last 15 years, the kind of, our story with Samuel, kind of. We coexisted, right, For a long part of our professional life. Ah. We met in the Netherlands in a, in a team that we were working in Rotterdam, right. So it was a company in the edtech space that we are building some very, very cool things there. Not with the use of AI back then, we are that old. So back then one of the things that we were really, really focused on and things that we were actually discovering was how to enable and how to empower our development teams ship and build faster applications. Right? So in a startup the pace was crazy, right? So we always wanted to be more and more productive and we always had this question like, how can we do it better? So after experimenting a lot, one of the answers that we gave to ourselves was third party services, right. So we said, okay, how can we make sure that we can connect to third party services and make the best out of it? Uh, we still found a lot of problems. So we were still not happy with how this worked for many reasons that we can, we can discuss in this podcast. But this basically resulted in APIhub. So our vision was to basically bring together all this experience. We're bringing, and Samuel was bringing particularly into the, from the engineering experience he had to create a unified platform where developers and teams and anyone building could be able to leverage third party APIs for any kind of functionality. So we call them utility APIs in order to build and scale their application. So that's where the initial seeds, let's say of uh.

Speaker A: Yeah, really interesting to hear about kind of how you guys met and started that.

Speaker E: Tell us.

Speaker A: Yeah, maybe, maybe a bit about yourself as well. Some will.

Speaker D: Yeah, I mean I've been uh, working for the last 15, uh, 16 years now, I mean in product engineering teams in various companies. I'm originally from India but you know I've lived all over Europe now, I mean over the last 16 uh, years. But I actually work with SAP. I did my industrial PhD with them in France in cloud security and assurance. Um, you know, because SOA was service oriented architectures, if you remember that. That was a thing that was all the rage and how do we bring assurance and everything and that actually. And uh, after that I mean I continue to work in, move to Netherlands, work for startups, scale ups, all of that. But uh, the, the work that I've done during my PhD and everything continues to shape what I'm building now. And actually what we are going to talk about is actually almost a uh, realization of the 10, 15 years work uh, that we've put in, into this topics.

Speaker A: Yeah, I mean that, that is, that is, that is great to hear because that really brings us to our topic for today. Right, which is, you know, who certifies APIs? You know that our agents are calling. Who it really almost.

Speaker C: Yeah.

Speaker A: Who certifies the APIs. Our agents are calling with this kind of, you know, agentic age, agentic driven API consumption and all those kind of things. But I, I want to, before we start talking about certification of APIs, you know, I kind of did a look I saw you'll be speaking at API days or as it's currently called, first conference in Amsterdam in a, uh, I think in a week. And by the time our listeners hear this it'll be like past. Yeah, but um, I saw, you know Samuel, you had this interesting thing about how APIs are becoming building blocks rather than integration points. You know, tell us a bit about that and your thinking, your thinking around that.

Speaker D: Yeah, I mean I actually believe that APIs and services in general, I mean APIs are just a means to connect to services. But Services were always supposed to be the building blocks, right? I mean as I was mentioning, service oriented architectures over the last 20 years now, I mean like, you know, when the concept emerged, uh, it was supposed to be uh, the idea was expose useful capabilities over the network through APIs and compose them, build faster, scale better, stay leaner. That was the whole premise and that was the whole promise of uh, that service oriented architectures brought to the table, right? But the integration points, I mean like, you know, is really the operational side of things, right? I mean it's how you define the contract, how do you integrate with that, how do you, how do you uh, deal with the authentication, the rate limiting and these kind of things are more operational side of the APIs. But the thing is what I feel has become over the last uh, 15 years or something is that the integration side became the story. We became more obsessed because there was so much of fragmentation. There was no consistency across the different uh, providers and so on. So we ended up with uh, focusing so much on getting that logistical side under control rather than actually looking at, okay, how can we really leverage the promise that the service oriented architectures actually brought to the table. And then, you know, we went on from there, right? So uh, if you for example, take S3, Amazon, S3, for example, nobody stops to ask and says I'm integrating with an Amazon SaaS product, right? Or Amazon infrastructure product. They think I need a capability of, for like an object storage. And S3 is just a means to that. I don't even know how many people actually think they're making a REST API call, right? So they just configure it, use the SDK, that's it. But behind the scenes they were using what service oriented architectures provided as a capability, right? Uh, but the problem there, uh, with external APIs especially, why we couldn't see the same type of adoption across the board is because every service tried to slowly go out of its, because every niche provider started to build a business around it, right? And everything, every micro capability became a SaaS product. Everything came with its own pricing, every different pricing models, different model, uh, of authentication and different uh, API contracts. I mean some go with rest, some offer GraphQL, for example, right? I mean like, you know, because that was a cooler thing to do at that point, for example. And so there was a lot of fragmentation and so on and so, but

Speaker E: ended up creating friction, right? And now when you start seeing the, all of this uh, problems, uh, now you don't want to see them as building blocks. You see Them as an external dependency. You don't see the same, you don't have the same uh, mentality when you look at an S3 kind of a service or when you see any other infrastructural service which has a consistent API pattern and a uh, very predictable pricing model, very uh, clear usage model and you know, uh, that's what a building block should have been in the first place.

Speaker B: Right.

Speaker E: So I think uh, for me uh, this whole concept of you know, the services or APIs being building blocks is not new. It's just that I think we need to go one level up now that agents and AI is taking care of the operational side. We have to start going one level up, you know, and think about the conceptual clarities of how uh, do we bring about capabilities that we can leverage. And you know, I can specialize in providing this one capability, but I want to provide it in a way that you can trust, use consistently and build your applications on top of the foundational blocks that I'm providing. I hope that's clear.

Speaker A: No, absolutely. Makes a lot of sense that you know, when, when you, yeah, that, that, that, that's a really structured way, you know, to, to, to look at it and uh, really will be, you know it's, it's an almost an extra layer uh, on, on those building blocks. Right. To take advantage of, of the building blocks. Now that brings me to my next question which is I know, I know you guys are working on something around certification. Right. And, and maybe I'll probably throw this question to Nicholas before maybe, I don't know. Samuel, you can also chip in if you want. But really what's been the driver to make happy Hub say, you know what, it's the, you know, there's a need for certifying these building blocks for certifying APIs. Right? What, and maybe, maybe talk to the listeners about what you mean by certifying APIs first and also secondly what the driver is for, that maybe talking to your customers, you know, looking at the market. Just what's driving you to that?

Speaker B: Yeah, I can give perhaps a uh, small tease, a non technical tease and then someone can pick it up. So what drove us to start thinking about uh, certification or compliance? I would like to put it better. Certification always has a kind of mandatory or things that you are ruling. Right. So I like more the term compliance and uh, clarity. Right. And transparency because this is what ultimately we want to achieve. So let me just tell you an example of what happened a few months ago. Right. More than around A year ago, actually, with one of our providers at apihub. So it's an API provider and they are based in Europe, right? So we were all fine. So we integrated. They had some amazing services, right? And then some of our customers actually were interested in these services, right? And we went there to implement them. And then someone asked, okay, where is this service hosted? Right? So I looked at Samuel and I'm like, Europe, right? I mean, we know the guy, he lives in Europe. So the data should be in Europe and the data centers, but, you know, it was not, right? It was somewhere in Asia. And this turned out to be a problem for the customer because, uh, they had European guidelines. I mean, you live in Europe or in the uk, so you know how this works, right? So it's not always very clear what the non functional requirements are, right? So we have the functional things, what an API does, which is the contracts, everything that we talk about is based on that, right? But what about everything else that is non functional? Where the data is hosted or how, for how long is data? Um, the data retention policies or what kind of. And especially now with the AI, what does the data is used for, Right? Are they used for training? Are they used for what? Right? Are we sharing any PII and any personal information? So all this stuff, which is basically translated into one word, which is trust, right? I mean, as a developer, you can go there and integrate tomorrow and you can ask the right questions, you can, uh, have a gut feeling even about a service or someone or read it. But then when you outsource this work to agents, this becomes complicated. And I want to give it to Samuel to actually put a bit more meat into that.

Speaker D: Yeah, yeah. And actually, I mean, yeah, the examples that you gave are accurate, right? I mean, some of the trigger points that accelerated us to get into the certification models and the framework that we ended up building over the last, uh, years. But the thing is, you know, if I go back to the point, the previous point that I was mentioning, building blocks, how a building block can only be useful if you can trust, uh, that building block, because you're basing it as your foundation to build applications on top of it, right? So you don't want to end up with a scenario like, you know, you build the most robust platform, but that one external service that you're using is the one that's sort of leaking data to, or dragging your compliance down the drain, for example, right? So that's the question, right? How do you make sure that, uh, you can trust the building blocks? And this Is where I think, I mean for Appi Hub in particular, like why did we start doing this is because we were actually in the right position, right place. We have consumers on the other side, one side, I mean like you know, who uh, who interact with us as the first point of contact on the platform. Because we are not just a directory of APIs, we are actually an API platform where services are hosted or are connected through our gateway for the services that we audit and record and uh, we admit into our platform.

Speaker B: Right.

Speaker D: It's a very much like a Apple App Store kind of a thing, but for services. Right. So uh, we have the touch point with the customers. We know what customers are looking for and everything and we know how diverse their needs are. And on the other side, I mean we onboard the customer during the onboarding of the providers, uh, we collect a lot of information about the provider, the services. We have the functional specs, we have the non functional specs which we were collecting already before. It's just that, I mean we realized, I mean we can actually use all this wealth of information and actually put

Speaker E: uh, it to good use and to

Speaker D: actually make the, the compliance checks for

Speaker E: the customers really seamless.

Speaker C: Yeah, right.

Speaker E: And uh, one other point is also we looked at other uh, service platforms

Speaker D: that uh, others are doing and you always, I mean you see this, right?

Speaker E: I mean like you know, a blue check mark verified.

Speaker C: Yeah, yeah.

Speaker E: You know, and as if that's enough to trust. Right. I mean but the thing is trust is very different for different uh, customers operating in different uh, jurisdictions, operating in different domains, uh, you know, dealing with certain data. It's almost use case specific. Can I trust the service to send my user data, user pii, personally identifiable information versus can I send some random stuff that is not confidential or anything like that. So it's also like a, uh, it's a, it's uh, it varies very widely. So there is no one size fits all, trust us, we know for sure kind of a thing. So we moved away from that badge type of certifications and actually went with the descriptive certification. We actually certified claims. Okay, what are you claiming? I mean how long do you retain your data? How long do you, how do you, why are you collecting this data? What do you do with the data? And then we verify audit and then we uh, issue the certificate. Right now it's for users or consumers to view that, uh, and we capture this in a machine readable format. So not only users now, I mean, but also agents can actually make use of this to make uh, better decisions.

Speaker C: Yeah, right, yeah, absolutely.

Speaker A: I mean, thanks Nicholas Ansemo. Because, um, you know, what you're talking about makes me think about a term I use sometimes which is consumption side governance. Right? Like API consumption governance, you know, because you know, having worked as kind of API product owner in a product manager in different companies, I know we, from an API provider side governance is usually talked about like how can we govern what we're building, how can we govern design, make sure standards are compliant or things like that. And it's really from the, almost from the production side but from the consumption and a lot of people kind of focus on the, you know, how can we build and publish APIs is you know, on a great dev portal, developer experience, all that kind of stuff again with a production lens on, but not so much there isn't as much focus on the consumption side. Like are we consuming APIs in a secure way? Do they have the right compliance? All the things you talked about, where is the data located, all the policies, you know, privacy and all those compliance issues, Are we doing it right? Do we know the APIs we're consuming?

Speaker C: Right?

Speaker A: Not just do we know the APIs we have, do we know the APIs we're consuming and do we have all those uh, great compliance checks things that you mentioned in place? And so I think it's a really good, uh, really good point you both raised. But I think that brings me to, you know, we traditionally think about obviously consumption from a developer experience point of view, I guess. But now agents like, you know, agents are everywhere and agents are consuming APIs. And I wanted to get your thoughts on kind of, in fact just this week I was also having several conversations on what kind of agent readiness means for eth APIs. What does an agent ready API mean especially as well, first of all, what does that mean for, for you? Um, because there's a follow on question on what that also means for kind of certification and compliance as well to, to agents. So what, what, yeah, what do you guys think about this?

Speaker D: Yeah, so for, for me for example, I mean an agent ready API is, it's, I don't see that as a special A.I. aPI. Right. Uh, I see this much more simply as an API which, where the agent doesn't have to guess.

Speaker C: Right.

Speaker D: And I, I, I'll try to think, organize this into three parts where I think, I mean what is important from uh, for uh, API to become like agent ready. Right. I think first of all there are certain things that we need to, we need to evolve in the, in the community and Everything which is like, you know we've done a great job with open API specs that captures the functional requirements really, really well. But that's just the baseline, that's the functional requirements. So. But there is a plethora of non functional requirements. The security uh, elements. I mean what data retention and purpose and privacy, gdpr, you know in terms of the even pricing, throttling, you know these are all things that are not in a machine readable way. So if, if an API, if an agent is to make a decision it can integrate an API because the X amount of plan is giving me this amount, this much throttling or whatever or consumption limits. But it has to understand what is the impact of. If I, if this were to be running in production, handling my production workloads, how can, can this API scale and can this model work for my organization? Right. So which is what a, normally a developer would do when they, when they review that. But uh, this is what an agent doesn't have an agent if it doesn't know the functional properties, it doesn't care about the non, uh, the non functional properties.

Speaker E: Right.

Speaker D: It is blind to that. So it is going to take the best possible API to get the job done. For example, you know, so you need to uh, you as in like I mean uh, we, we all have to as a community I think I mean like to have work to work on this non functional specification standard that, that we can all use. And of course there are initiatives, don't get me wrong, there are several initiatives always that, that deal with these things. Several that I mean I have been involved in, in the, over the last 10 years, I mean in research, uh, projects and everything like you know, but nothing actually commercially uh, has been adopted at a wide uh, in a widespread kind of a thing.

Speaker E: Right.

Speaker D: I mean like just if you compare it with the Open API standard you don't see that uh, the equivalent of that. So I think the machine readable uh, artifacts for the non functional specs have to be there because that takes away. So it's still in my view it's still an API specification, it's just that it's specifying the non functional properties.

Speaker C: Yeah.

Speaker D: So that I think needs to evolve first of all and every API needs to have both of them combined in one place. That's number one. And the second thing I think uh, and this is more broadly speaking is that our ah, standards need to evolve. Standards like OAuth for example.

Speaker A: Right.

Speaker D: I mean it's a brilliant framework for you know, delegated access and all of these things. But when it comes to agentic workflows, you know, uh, you have to think about scenarios how uh, how can you authorize or how can you delegate an API, an agent to call an API on behalf of a user? So how do you time bound it? Like you know, how do you make it task bound? How can you uh, make sure that the intent that it is accessing certain data is clear, for example. So uh, I'm sure that, I mean like you know, uh, I was talking to some leading identity providers recently, I mean uh, and they were all saying like, you know we are all working on finding a solution to this and I'm sure that you probably have heard about it. I mean like you know there are initiatives starting around these things as well, right? I mean, so I think that is also important because otherwise you end up with uh, giving two fine grained permissions or two coarse grained permissions right now, and especially in an API kind of a space. And uh, I think that is not going to scale well. And the last thing I would say

Speaker E: for an API or an agentic use,

Speaker D: uh, for APIs to be ready, I

Speaker E: think the intent of the API design has uh, to become very clear in the API design. So how much surface area are you, you exposing to the agent? So for example if you take like uh, an E Commerce sort of a thing, right? I mean where you have, you allow, you have APIs to browse products, add it to the shopping cart, uh, apply a discount coupon, add the billing address, check, whatever and then go on to checkout place the order, right? But so you can provide all of these different endpoints a uh, broader surface API surface for the agents to use because it can actually then cater to different types of use cases. But in other cases where for example if you want to submit a document and extract things from the document and convert it into some, transpose it into a different format and then do something with that and send uh, finally a mail to somebody else. I mean with all the extracted properties you don't need to break it down into fine grained steps because for an agent it doesn't matter. And increasing and offering the complexity uh, to that is just going to increase your token consumption and all of the, you know, all the underlying or the other wasted efforts, uh, unnecessary. So the design has to be very important like you know, what surface area are you presenting to the agent to integrate? So I think, I mean if we can do these three, four things, I

Speaker D: think it would be um, really, really, really uh, we would end up with a very really scalable model. That's how I would say it.

Speaker A: Yeah, makes sense. And you uh, know, while you were talking you, you, you mentioned this kind of machine readable certification layer. You know, have a standard machine readable layer on compliance. You know, but you know the thing with standards and you know we can talk about all the XKCD jokes around that. Right. The thing with standards is we need multiple people to come together and actually agree that you know, this is, this is the standard we want to use if it's going to get wide adoption. Okay, what, what do you think about. And uh, like you said, you know, you know, you've been part of efforts, you know, there have been efforts in the past around this kind of thing. But what would you think that would really make a, that would lead to a widely adopted standard for certificate for specifying this non functional requirements, uh, of APIs in a, in a standard machine readable way that agents can assume. Yeah, go on.

Speaker B: Just to add one thing, just one thought here. And then again, Samuel can expand on it more like I have been working as well, I mean not in service certification in the past, but in process certification. So I have been to many 27k audits or even in the past 9001 or whatever that is. Right. And a lot of times that I have seen that it's not that the standards are bad or that they're not very inclusive or whatever, but think about it, that even if the standard is perfect, imagine that. Let's assume the standard is perfect. When I come as an auditor to check you, what I will check is your performance and how well you complete the standard that day. Right? So the next day, uh, who knows, right. You need to have an auditor coming every day checking your current data, uh, checking your. How you currently do things in order to do what we are thinking about. So our approach is not only questioning the standard themselves, but actually making it current machine readable and something that actually evolves and changes through time.

Speaker D: Yeah, yeah, I think, uh, exactly. I think uh, certifications, I mean, like, you know, my gripe with certification is that it's always a photograph.

Speaker C: Yeah, right.

Speaker D: And while it's useful to say, okay, this is how it looked, but in services that doesn't work at all because you have, you know, it, it might used to work for software, I would even challenge that. But uh, but with services, I mean you have deployments that can go 10 times in a single day and you have the next deployment that might break the certification that you just received.

Speaker C: Right.

Speaker D: So that's the. So I think what I have come to the realization is that if you make certification only as a means of compliance, people are going to be fine with a photograph. People don't want to innovate because they're happy with that. But if you make certification or. But what are certificates, claims and non functional properties and everything machine readable and everything useful. If you make them useful and add utility value to that, then the adoption is going to increase.

Speaker A: Right?

Speaker D: Because what the thing is, agents are producing software left, right and center. So you have more software being produced now than at any point in the history and that will only continue to grow.

Speaker C: Right?

Speaker D: So we are talking about who verifies not only what the agents are producing, but how do you check what the APIs agents are consuming in the first place?

Speaker C: Right.

Speaker D: So uh, it's so easy now to build a micro SaaS application over a weekend. How can developers who have their hands full with other things and everything can go into the history of every provider to say okay, when did they launch, what company was it? I mean, where are they located, all of this. So that's the whole point of trying to make, trying to make the utility

Speaker E: of the certificate itself useful.

Speaker D: Then I think, I mean the adoption, and I use the example of SSLs, the HTTPs certificates, right.

Speaker E: There was a point where it seemed like, you know, uh, it's going to slow things down because it's going to encrypt all the traffic and everything people saw. There were some people who saw that almost as a hindrance. But now we can't imagine a world without HTTPs.

Speaker C: Yeah, right.

Speaker E: So it's always going to, I mean like if you add and you. And the way the uh, how did it become so widespread is because there were browsers that actually baked in the support for HTTPs. They were showing that this site is secure. I mean like, you know, that's the utility of the certificates, right? So the more uh, value that we are creating out of the certificates, the better the adoption is going to be. Specification needs to be there. The specification is just the first step, but we need to create the entire ecosystem around the utility, around the certificates.

Speaker D: So that's my view there.

Speaker A: Yeah, again that makes a lot of sense. Let's talk about the enterprise, right? Maybe about the. Nicholas, you were talking about process audits, right? So let's talk a bit about the process and people side, right? What do you find in terms of when you talk to your customers or when you talk to companies around who in the organization is really interested in checking whether the APIs we're consuming are actually compliant, who are the people who are interested or should be interested in checking all these things, that kind of ownership around, around that so that if this third party thing goes wrong, who's to blame? Like again, accountability. So a bit about process and accountability thing around API consumption. What do you think, you know, either application owners or engineering managers or people like that, application architects should be thinking of around that consumption and compliance.

Speaker B: Yeah, yeah. So a lot of points there and unfortunately, I don't know who wants to take this.

Speaker D: Yeah, I don't know. I mean, I can take that. I mean so if you look at the process as a whole, right? I mean like, you know, what happens is developers today find a service that meets their functional requirements and maybe they check who the provider is and what they're doing and some basic stuff, uh, and then their leads check the other properties. I mean like, you know, okay, how is the pricing, is it going to scale and so on and then it goes to security, uh, teams that will check other properties and everything. And then there is the entire procurement process that has to, you go through the vendor selection process and all of these kind of things, right? So there are multiple stakeholders in the process. But the thing is in terms of when things go wrong, who's actually taking ownership? Because I think it's very unclear because there are just so many stakeholders and they, and what we are, uh, and even if they find it much later in the process, in the evaluation process, there is a prototype already built, it already hit the production and everything. So you know, in the industry we hear the term shift left, right? I mean like, you know, as early as possible with API design and everything. That's what we're trying to do, right? I mean like, you know, get the design right as early as possible, right? What we're trying to say is like, you know, shift left for the security and non compliance as compliance requirements as well, right? Check them as early as possible, right? When you see the service, look at the functional, look at the non functional right away there, right? The earlier we can move the filter out the things, the better it is, the smoother it is in the process. And of course then the uni also need a tool support, right? I mean a platform kind of a support. People have to approve APIs. I mean like, you know, who are, who have shortlisted in your organization, right? And who has taken the decision. A lot of the times this falls between the cracks, right? So I'm talking about third party services that are getting used, right? I Mean, like, you know, a lot of people get involved, but there's no clear ownership a lot of the times. And again, I don't want to paint, uh, with a broad strokes everywhere there are organizations that do this very diligently, but there are many, many, many organizations that actually are quite lax about it because they assume the provider to be. Or somebody would have already checked all of these things in their organization.

Speaker B: Just to add something, uh, again, on what, uh, I think you mentioned also about who is to blame. Right. When something goes wrong. Right, yeah, blame.

Speaker A: You know, big, big word, blame. Uh, we, we don't want to blame people. We want to, let's say, hold people accountable. Maybe, maybe that's a better way to put it.

Speaker B: No, I mean, I thought you mentioned also when, when an API breaks on production, if it's the provider's fault or if it's the, the, the companies. Right, yeah. That's also a song right now. Right. Uh, that.

Speaker C: Okay.

Speaker B: When, when something is wrong, basically. Right. So the consumer will basically try to say that something is wrong with the, with the setup of the provider and vice versa. Right. So what we see with the, with this transparency in this compliance layer is to give more, more visibility into how everything works. Right. So to make the consumers ask the right questions, as Samuel said, very early onwards. Right. So that if something goes wrong, we don't always, we can, we can't always avoid it, but we can actually make sure that we identified as early as possible throughout the process.

Speaker C: Yeah, yeah.

Speaker A: Just let's say I'm, you know, director of, I don't know, platforms. Um, I'm, um, some sort of engineering manager and organization, and I oversee several teams. I don't even know all the APIs these teams are consuming in the, in the first place. Like, it's not cataloged anywhere. I might have an inventory of my APIs, but I certainly don't have an inventory of the APIs. Ah, we're consuming. Okay. And so not only do I not have an inventory, I don't have a clear picture of these compliance aspects you mentioned around data retention services and privacy and all those things. Um, where do I begin? So, yes, presumably in the process of onboarding those third parties, at some point, those, those, uh, APIs might have gone through that process before the enterprise actually signed the contract, perhaps.

Speaker C: Yes.

Speaker A: But, uh, where do I begin to provide that transparency? Nicholas is talking about on what I have and, uh, what their compliance posture looks like? What are the questions? What are the top 1, 2, 3 questions? You would say that, um, people in charge of this should be asking of their teams information they should be gathering.

Speaker D: Yeah, I think the first, I mean the top questions is like, I mean the top priority questions would be first of all, understand who the provider is, where they're hosted, where the data residency is because a lot of the stronger requirements come from that. And then try to understand. The second, again, I'm trying to base this on my conversations with a lot of organizations who are consuming third party APIs and based on what their concerns are. The second one would be the retention. Lot of the times I think this is a mistake that developers make is that when, when they make a transactional API call.

Speaker C: Right.

Speaker D: For example, I want to do a file conversion as simple as that. I mean I want to process the file into this thing that, and extract some data out of that. Great. They might think it's transactional. I'm sending the file, it's, it's deleted as soon as the request is uh, processed. But seldom is, uh, that is the case. Um, there are copies made for whatever reason, the decision that the provider made for uh, the scalability or whatever that they're thinking of better resilience or whatever. But okay, they do store it. But how long do you store it and what is the purpose for you to store it? Why do you even need to store it?

Speaker C: Right.

Speaker D: So the retention and the purpose for the data collection has to be extremely clear. Right. And then of course there is other series of, you know, like it's a long tail of non functional requirements that you have to go through. Security, privacy and everything. But try to understand these three things first because that will tell you a lot about the provider and the provider's posture in terms of security and compliance.

Speaker C: Yeah, yeah.

Speaker A: And uh, I don't know if you want to add to that, Nicholas, but just if I say if we look forward, just as we kind of round up, if we look forward over the next two years, where do you see this kind of compliance certification side of API consumption going? What would you like to see in the industry around, around this?

Speaker B: Again, I will speak in general sense, but I think that my vision or our belief is that this will become like the example that Samuel said before, around ATP combination, et cetera will be the standard, right. It will be something that people will not really talk about in podcasts. It will be something that people will take for granted or that uh, they will expect to have for granted. And again the certificate, they, I prefer to call it compliance because we are not really talking about setting a bar.

Speaker C: Right.

Speaker B: We are not talking about quality, we're not talking about certain criteria being met. We are talking about transparency and we are talking about ways to show and understand what is happening. And as Samuel said, uh, I think I read it somewhere that in 2025 there were 1 billion pull requests on GitHub and 1 billion, it was just last month. Right. This year. So the amount of, of code that's being created right now is enormous and without certain controls and uh, transparency we will be in trouble. So that's the idea and the way that I see it in two years is becoming the de facto things that people are looking when integrating with APIs.

Speaker D: But just to add to that, uh, you know, you probably have seen this in the last, again few months all the security incidents that came through because of supply chain attacks.

Speaker C: Yes, right, yeah.

Speaker D: So the, and it's increasingly becoming very obvious, I mean like, you know, that the pace at which agents and malicious actors are murky, making the waters murky, you know, intertwining with uh, all of the other code that is being generated and sort of sneaking their way into it. And I think the supply chain security is going to be extremely crucial both for libraries that you use in your applications and external services. And I think npm, uh, you know, js, I mean like, you know, or the Python whatever libraries, I mean like, you know, the services that uh, that host these libraries, internal repositories or external repositories, have to put a certification layer also for the libraries. We already have that to uh, some extent. But certification before you allow certain thing to be there, added to the library because the risk of a supply chain poisoning the global software pool is huge. And we want to do the same thing for services.

Speaker C: Right.

Speaker D: Because, and I think, I mean like, you know, and I hope somebody does it for the libraries as well because I am every day worried about it around my own supply chain, the supply chain around what our providers are using. We ask them for the software bill of materials, for example, we verify all of these things.

Speaker C: Right.

Speaker D: But uh, it has to be in a scalable automated manner. And I hope in the future, in the two years we have these standards uh, put in place that we can actually just like we check the hash who provided the comment or who provided this. We should have this certification layer for both of these things to say that, you know, somebody has either manually or AI assisted has verified these things.

Speaker C: Yeah.

Speaker D: So we have to live in a world, I hope, where we can trust the building blocks.

Speaker A: Yeah, absolutely, absolutely. Look, thank you. Thank you, Samuel. Thank you, Nicholas. It's just been great, uh, you know, talking with you on this area. And this is an area I'm going to watch. You know, I think it's a area, it's a space that everyone should be watching because it's a, uh, it's. I think it's a space that hasn't been given enough attention, you know, in the past, whether from API platform teams and API governance functions. But do tell us, do tell the listeners, uh, where they can, if, if people want to find out about, more about you guys, what you do, you know, where, where, where can they find out? Where, where can they find out, uh, more about you?

Speaker B: First, they should come to Amsterdam next week to, to come to API days, which, which I was very disappointed to hear that you will not be here with us. Yes, it's okay. In the next one in Paris, perhaps. So first of all, we will be happy eight days and we are also trying to be more out there in other conferences and talks and be out there with the community. Uh, but other than that, we are on our website, we are on LinkedIn and on our, uh, socials, and we'll be. As we are evolving, we will be sharing much more into this about the certification, about the compliance, the APIs, more and more. So we are very active and present.

Speaker D: So you can find a lot of information on appihub.com.

Speaker C: okay. Yeah, yeah, yeah.

Speaker A: And yeah, thanks. We'll be putting the link to appihub.com in the show notes and also link to you guys. Uh, I guess people can find about your LinkedIn as well. I guess.

Speaker D: Yeah, absolutely.

Speaker A: We can put links to your LinkedIn as well, or any of the links you recommend in the show notes for this, uh, for this, uh, for this, for this episode. Look, thank you so much guys. Um, it's been nice chatting to you. Is there any one last word you want to say to our listeners before,

Speaker B: before we go, Samuel has last words.

Speaker D: No, I mean, for me, I think

Speaker A: somebody's gonna say being my talk next week, be my talking.

Speaker D: No, no, I, I'm conscious of the, I'm conscious of the fact that this is going to come after the talk.

Speaker C: Yeah, that's true, that's true.

Speaker D: So, but I, uh, think my, uh, message would be. I mean, I think it's more of a, um, uh, sort of a be aware kind of like a public safety announcement kind of a thing. Is that please really take care of your dependencies.

Speaker C: Yes.

Speaker D: Uh, you know, because either your libraries or your, uh, services. Because I think we, we are assuming that there is somebody out there looking for it and making sure that, you know, if it's open source, it must be safe. If it is, uh, you know, if ten hundred other people are using it, it must be good. You know, social proof is not enough anymore. So be more vigilant about your own dependencies that you're using in your application. I think this is extremely important and we are living in times where I think this is going to be extremely, you know, uh, we are opening ourselves up to different types of attacks and, uh, just be watchful for that.

Speaker A: Yeah, social proof is not enough anymore. I love that line, Samuel. I love that line. Look, thank you guys. It's been great talking with you and I'm sure I'll bump into you again somewhere, but anytime very much, and we'll keep in contact.

Speaker C: Okay?

Speaker B: Thank you very much. Thank you.

Speaker D: It's great to be here again.

Speaker A: Um, bye.

Speaker C: Bye.

Speaker B: Bye.

Speaker C: Bye.