Exploring the ins and outs of API monetization (w/ Kin Lane) | All About APIs Ep 001

Welcome to All About APIs. On this podcast you’ll hear from seasoned API practitioners, product leaders, and architects on what it takes to successfully design, launch, and maintain APIs that unlock new growth opportunities.

Hello and welcome, everyone, thank you so much for joining us. This is the All About APIs podcast. I’m your host Budha, the product evangelist at Tyk, and over the course of the season we have been covering topics associated with API-led product growth. During that journey we’ve explored a lot of different aspects, different elements of this specific area of API-first products. Today we’re going to be deep-diving into the world of API monetization, and joining me on that journey is the one and only Kin Lane. So hello and welcome, Kin, it’s a pleasure, it’s an honor to have you with me.

Thank you for having me, Budha, this is awesome. I’m so pleased to be here and helping y’all with your podcast.

Wonderful. So let’s kick things off, perhaps a quick introduction of all of the things that you’ve done, your fascinating journey, a fascinating career that you’ve had so far. You’ve got your own podcasts, you’re writing your books, you’ve got the blogs around the API Evangelist, which is kind of an interesting one, because when I started off as an evangelist that was the first thing I searched, and I wanted that name so bad, but anyway, let’s just talk about you. A quick introduction perhaps into your world.

Happy to. So first of all, Kin Lane, I’m Chief Evangelist now at Postman, but I’ve been known as the API Evangelist because I’ve had this blog since 2010. I think it’s about 5,000 blog posts at my last count that I’ve written in a decade about APIs. What I was doing before API Evangelist, I’m a database expert, so I’ve been doing databases since the 1980s, just to date myself there a little bit. But fast forward, I’m doing database-driven web applications, service-oriented architecture, I’m building websites using databases, and I saw the ways APIs started being used in 2006 with Amazon Web Services, and then 2008, ‘09 with the iPhone and delivering resources to mobile applications on iPhone and Android. And I was like, there’s something here, because I’ve been using APIs for a while, different shapes and sizes, but I saw groups really starting to get organized, and it was right about that time that I saw the concept of API management codify in the way things were happening, and I saw companies getting more organized about how they do APIs and having deliberate business strategies around them, and I just wanted to understand it more. And 12, 13 years later, here I’m still doing it. I’ve helped a lot of enterprises with their strategy, I’ve worked for federal government, I worked in Washington, D.C. for the Obama administration, I did work for the European Commission on API standards across member states, and then found myself in 2019 joining Postman to get a little bit more practical and hands-on in how I do APIs rather than just talking about them.

Wonderful, that’s been quite the journey, and following your work through the years has been absolutely amazing. The blog posts were pretty much my first foray into evangelism, started with your blog posts, and then looking forward into when you started Breaking Changes as well, which is your podcast, and again great conversations, we actually had Deepa as well joining us for one of our conversations, which has been absolutely fascinating speaking with her. So yeah, absolutely a big inspiration for myself and certain people in the industry as well. So with that introduction, thank you so much for that. Just moving on to our topic for today, which, given your background, looking at all of the different aspects and the journey, the history of APIs, where we’ve been, where we are, coming towards the evolution of how businesses are approaching or thinking about APIs, whether that is an API-first approach to things or API-led product growth, a big conversation topic these days is productizing and monetizing APIs. But in a lot of cases there is an oversimplification that goes around that, which is, API monetization is basically getting paid for your APIs and how do we make that possible. So a lot of the conversations tend to be driven by that, but obviously when you get into the weeds with them and exactly what they’re actually looking for, that is far from reality in some cases, where you don’t have the basics in there. So I just wanted to get started with your thoughts and opinions into the world of API monetization. What is it, how do you view it, and what are the different aspects of it?

Yeah, it’s an interesting realm to dive into, and there’s so much nuance and detail to it, and it’s one of those things that you’ll get 10 different answers about what is API monetization depending on which 10 people you talk to in the space. It’s what I mentioned briefly, with the API management providers when I first started API Evangelist, watching what Mashery, Apigee, 3scale, and the earlier guard of API management providers would do. They would give you the solution that said, hey, you could publish a portal, you can publish your API docs there, you can have developers sign up, and then you can charge them per API call. And there’s very much this “you build it and they will come” kind of mentality, like, hey, just put out an API that’s really cool, people are going to come build really cool things, and you’re going to be charging for that and you’re just going to get rich, and that’s how it’s going to happen. And I believed it when it first, I kind of bought into the messaging, and then you start realizing, well, there’s so much more to actually doing an API than just the technical of an API, or the business of making it public. And you mentioned it there with product management. There’s a lot of nuance to how you build these products, what makes an API a product, and a lot of people in the space, because of API management vendor marketing, are really saying, hey, if you just publish your API publicly and you’re charging for it, it’s a product, done, all right, let’s go to the next thing. And it’s like, no, there’s actually feedback loops involved, there’s actually a value exchange, there’s a lot more to it than just the API management vendor vision of it. So when you ask people what it is, they recite a lot of what they’ve been told by vendors, but once you’ve been watching it for a while you realize it very much is about value exchange, which sometimes there’s money being exchanged as part of that exchange, but really it’s about defining your digital resources and capabilities and now experiences, putting it out there, and then being able to actually understand the value that’s being exchanged around that, like those consumers of that. So us as API producers are producing these experiences, these digital resources, we’re putting them out there, consumers are using them, and we’re measuring that, we have API management in place that tells us how many calls they’re making, what they’re using, we can even invoice and send them an invoice saying, hey, here’s how much of that you used, we can charge different rates for different resources and different experiences for different partners, hey, you get this for a hundred dollars, you get this for fifty dollars, and so we can create different financial experiences there. But it’s not always just about the direct revenue, and it’s not always about charging. I tell a lot of companies they should just focus on understanding who’s using and measuring that value, and then providing them an invoice of that value, but maybe you’re not actually charging their credit card with Stripe, but you are communicating that, hey, I did this for you, you accessed so much, and it has this value, and let’s have a conversation about maybe how we can iterate or evolve on this value and keep it more in alignment with your business goals. And that’s really where I see the most important kind of API monetization activity happening right now, around product management, those feedback loops, those iterations, and finding that alignment between not just development and business but the actual consumers of these digital resources.

Absolutely, I think you’re absolutely spot on. The thinking a lot of times is that you’ve got your APIs, let’s design it, let’s build it, and that is the end of it. But typically, even from our perspective, when we think about API management within that cycle, we see that it’s, if you think about what would be useful for our API consumers, why, what is the purpose of actually having an API, then the design and development of the API is probably step one or two out of maybe a five- or six-step process. So you need to still think about, obviously on a larger scale, the purpose and the value that it’s going to be bringing, but equally even from a more technical standpoint you need to start thinking about how are you going to be securing those APIs, how are you going to be versioning it, how are you going to be putting in those governances in place, how are you going to be actually exposing them in a way that is easy to find, easy to document, easy to search, and then obviously adopt for creating their own products if you’re sending it out to your API consumers. So the overall flow of value exchange, and I think a lot of it is to do with a change in mindset, where, like you said, the early days was really about, let’s build APIs because that is the new thing to be done and everyone is doing it, why shouldn’t we be doing it. And it’s a lot of that mindset which involves people and process, and obviously there’s the product side of things that comes into the whole equation. So my question, you’ve obviously mentioned a little bit about the value exchange spectrum of things, if organizations were to start thinking about it, let’s say today, they are thinking about API monetization as a way to scale up their business, or as the next iteration of their business, what would you say would be a good first step for them to start thinking about it, where right now they don’t have anything in place, they’ve got their core infrastructure in place, they’ve got some value that they’re providing with their product, now they’re looking to take up the next step, which is where you’re looking at API-led product growth, they’re looking at new launches perhaps, or new regions, or maybe a new customer segment that’s coming out too. What would they benefit from having in their arsenal, as well as what kind of mindset should they be going in with?

So this is an interesting one that I’ve recently changed my tune on. Historically I’ve always said start small, start with a side API, a low-hanging fruit, something that’s not going to cause too much damage if you make some mistakes, and wrap it in an API management solution, get some reporting, get some awareness on who’s using it. Because if it’s been in the shadow, if it’s an existing API, it’s been in the shadow of a mobile app, you probably don’t have that visibility and awareness into how people are using it. So start there, and then look at your reports, get to know how people are using it, build relationships and connections with those consumers, and then iterate from there. Now I’m changing my tune on that, because here’s the narrative that I’ve heard play out several times: we launched an API portal, we hung some APIs in there, we held some hackathons, we got some people using it, it was great, but it really wasn’t much business value generated, and the program got cut, the program got axed, we lost a couple of people because we didn’t have the business impact we needed. And so now I’m recommending that folks, I don’t say go big your first time out, because you’ve got a lot of learning to do as far as how to tune into those analytics, build empathy with your consumers, there’s a lot of things that have to happen at this layer, so you don’t want to always just go big if you can do it. But right-size it. Pick a project that will have some business impact, something you can point to and go, look, if we just did more of that, then our business would be on the right track. And so that monetization piece, it has to be right-sized, but still pick a project that isn’t too ambitious, that is going to have room for you to learn, get plugged into those analytics, understand what’s happening, and be able to iterate and evolve and learn, because that’s really that muscle that you develop around that iteration and those conversations, and your API management dashboard, that analytics is going to give you, that’s going to evolve over time, and the sooner you can build up those muscles the better off you’re going to be. But you still need to come out of it being able to go, hey, this has real business impact, this isn’t just a hobby, this isn’t just a side thing, it’s not just this coupon API that no one actually cares about, you’ve actually got to go bigger than that.

Absolutely right. I think it’s that sort of balance that you need to make, where you’re trying to start small but at the same time you’re trying to provide enough value, like you say, to your API consumers, that it’s not so simplistic where your MVP is defined to be so simple that it just about works, and in most cases people have kind of evolved today to say, I don’t think we need just about works, we want it to actually work for us and solve an actual challenge for us, and therefore we are going to be adopting it. It doesn’t have to be, like you say, massive, but it’s going to be something that is still meeting a specific job to be done in an organization. I think that’s probably what the approach is in an organization typically. And in a conversation with some of our sales team folks and customer success teams, I think they are always emphasizing, how do we take the conversation from, oh, this is fantastic, this is great to have, to a conversation where it is, we must have it now. And I think that transition is the trick to success perhaps for an organization.

Yes, yes, you have to be it. And that’s the thing with APIs, is you want these baked into people’s applications and integrations, and you want them needing and depending on that, because if it’s a nice to have, there’s not a lot of loyalty in this day and age.

You touched upon another point there, where there is a lot of emphasis on just understanding how your product is being used. Obviously if you are starting off in an appropriately sized manner and you’re trying to grow from there, an important aspect, like you mentioned, is going to be metrics, and I think we had this conversation previously in another of our episodes where we were really looking at metrics that matter. So when organizations or people are experimenting with this and they’re getting started, what would you say are some of those metrics that they should be focusing on, that they should be benchmarking, and therefore leading them towards making the right decisions for their product?

Yeah, so early on, the thing with the API management layer that I find fascinating is, if you take it at face value, you stand up an API, you put an API gateway or management layer in front of it, and you have a set of very technical metrics: number of API calls, frequency, error rates, maybe a little bit on service composition, meaning they’re in this usage plan, they’re using these APIs, so you have some very technical metrics. But for people who are early on, you’re building digital resources, meaning you’re putting out these resources, creating, reading, updating, deleting those, and you want to see who’s using them and at what rates, and maybe charge them for those raw resources. But where I see people really progressing is they don’t just have a base buffet of digital resources, but they’re now stitching those together into more meaningful business capabilities that actually accomplish a business goal. So for example, digital resources are products or orders, where a digital capability is your product search, your shopping cart, and your ordering process. So it’s very much stitching together those resources into a capability for your business. And then the third mature aspect of that is you’re building experiences. So this is like, oh, I just found this product on Instagram and I one-click bought, purchased, frictionless experience, and it was smooth, easy, I got what I wanted. And so how you build metrics into those experiences, and to go from resources to capabilities to experiences, and then measure and track and build awareness around what matters, that awareness building is really what your API management layer is for. It’s not just about authentication and security or reporting and analytics, it’s about awareness building. So it’s not the dashboard, it’s what you learn from that dashboard over time, watching, and then you can tweak and dial in your metrics to be more meaningful. And here’s an example of that. The most common thing we say when it comes to onboarding new users is that time to first call. So someone googles, says I need an X, Y, or Z API, they discover, land on your API portal, they register, they sign up, they get a key, they’re looking at your docs, they understand what’s possible, they’re able to make their first call. So that whole journey right there, you want that time to first call as short as possible, because if I have to sign up and wait 48 hours, you probably lost my attention. There’s a lot of things you can do in there, so that time to first call and reducing that’s been a big focus point. But you mentioned Deepa earlier, and Deepa, when I did my podcast with Deepa, which resulted in me hiring Deepa, bring it around to my team, she mentioned time to first value. So it’s not just time to first call, it’s picking an API endpoint that represents value to producer and consumer. So it’s not just, oh, here’s the first API I call up that I’m getting charged for, I guess that’s a very simplistic way to look at value, but come up with some other part of this journey, that, oh, I made my first call, but now I’m making the series of API calls that show it’s integrated into my app, it’s supplying my customers or my end users with what they need as part of my application experience. As a producer, come up with those ways of defining what those API calls are, and then track that time to first value. How do I go time to first call but rapidly go past it to generating business value and meeting those metrics that your product managers hopefully have set and are working towards as part of what they do.

Given your background as well, working with standards and in the government space, I would imagine a lot of those conversations would come up where standardization as a mechanism for growth and not as a mechanism for inhibiting innovation is kind of the idea. Now how much that is executed or not is probably debatable, but I just wanted to get your thoughts on standardization as well, and the OpenAPI standards and open standards in general across maybe financial services or just in general API consumption. What’s your take around that, and what do you think is maybe missing, or maybe it is doing what it’s meant to do?

Yeah, standards are interesting, because it’s another one of those words that means different things to different people, and I have a very fluid definition of everything from internet standards and IETF, you know, HTTP is a standard, standards are good, we should do this, and then industry-level standards, you mentioned PSD2 and others, FHIR specification for healthcare, but then there’s a wide range of other types of standards, OpenAPI and Swagger, JSON Schema, standards are good. But just standardizing is so important in what you’re doing, because the sprawling digital landscape that has emerged over the last 20 years to support all the website activity, all the mobile app activity, every project to come along, integration, partner, just every ad hoc thing to come our way, we have this sprawling landscape that isn’t standardized at all, or very rarely, but it has some standardized elements, we’re using HTTP for a lot of it, that’s a good start. So anywhere you can standardize is so important, and Swagger, OpenAPI is an important first step. A lot of people just purely see it as documentation, oh, this is just so I can generate docs, others will see it, this is just so I can generate code, SDKs, and I can auto-generate. I see OpenAPI as, hey, this is us getting on the same page, so when I say this path has three properties and here’s a schema that you’re going to get returned, you know what I mean when I say that, it’s precise, it’s machine-readable. It’s not always as precise as we would need it, but it’s much more precise than we’ve been. So just doing Swagger, OpenAPI to map your landscape, this sprawling landscape, and standardize what you’ve already been doing so that we can see it, because APIs are very hard to see, and this is why I think API management is so important, because these APIs have emerged in the shadows behind our mobile applications and we don’t see them. So it makes standardizing in any way, or steering in one direction or another, or eliminating redundancy and being more efficient or being secure, much more difficult if you can’t see it. If you’re not aware of it, you can’t change it, you can’t secure it, you’re never going to be able to do any of those things. So standardizing for me is really just about getting on the same page, and API management is really key to that, because that’s how you’re going to bring visibility to all these APIs. We’re going to have a contract between producer and consumer for each of these APIs, it’s registered in the gateway, and now we’re on the same page, we can start having a conversation at scale across many teams about what needs to happen, and we can have guidelines and standards for, now, what should we be doing to further standardize, further stabilize this forward motion. And you’re never going to be able to do it without standards.

It’s very interesting, because if you think back about the philosophy behind why APIs came into existence in the first place, it was really to have that universal language. It is the language of service-to-service, system-to-system communication, it is meant to be that standard language. But I think somewhere down the line those languages got fragmented by dialects, as we call it, in terms of API styles, and you’ve got people who have their own variations of it, their own versions of it, because the initial definitions, while they were still better than no definition, I think they were a bit loose-ish, I would say, so they left a few things to interpretation, and I think that’s where some of that fragmentation came in, and how people were implementing it wasn’t standardized, therefore making it harder to integrate, harder to actually accomplish the communication that was prophesized or promised with APIs. It probably did a good job communicating with their immediate systems, but I think more on a global level where we’re looking at inter-system communication, not just through a small set of services but perhaps something a little bit larger than life, and that’s kind of where we are getting to now with the standardized practices, where, you know, obviously some of the open standards, like the OpenAPI specification, great starting point, something that we’ve been really excited about here at Tyk. But even thinking about open banking and PSD2, of course there is still room for improvement with some of that, but again the philosophy behind it, which is something that I absolutely love about APIs, when I think about technology, the philosophy behind why some of that stuff exists is always something I find fascinating. Because when you think about standards, a lot of those standards were built because banking systems, if you wanted to integrate with any of the systems, everyone did their own thing, and to be able to, as a fintech perhaps coming in to provide some form of value to the consumers, if you had to integrate with a banking resource in some way, that would have meant pretty much trying to speak 10, 15 different languages to be able to actually communicate and bring something together. And bringing that right value with that standardization, the promise of that standardization is that now you are, like you say, on the same page, and therefore, now that you’ve got the basics out of the way, your foundation stuff is done, you can start with your innovation journey and you can start with your growth promise that you’re really looking at. So with that, really quickly, on to some of the examples that I’m quite curious about, because we’ve spoken about standards, we’ve spoken about how organizations can get started. I’m very curious now, given your years of experience in this field, what are some of the organizations that you have seen who’ve done this well, maybe you don’t have to name them, but what were they doing right, and on the flip side of that, organizations who got it horribly wrong, and what were they doing wrong?

So one of the ones that has been doing it right is the U.S. Census Bureau. So this is the federal agency in the United States that’s in charge of counting the citizens and creating the demographics. And when I first started talking to them in 2011, they produced downloads of their data, so you can get the 2010 census as a massive download. And I said, hey, how have you thought about making that available as an API? And they’re like, oh no, no way we could do that, we just gotta make this available, we can’t put our opinions on it, and API management would be us putting our opinions, locking it up, we gotta just make it available and let people use it. And I’m like, well, it’s a multi-gigabyte download and it’s pretty complicated, not everyone has access to make sense of that and has the resources to do that, so you’re immediately being opinionated about who can have access to it and who can’t, so you’re doing what you just said you didn’t want to do by doing what you’re doing. And I’m like, do you know what Google’s doing with your flu information and tracking flu around the country? Are you aware of what, not Mailchimp, I forget, it was a data company out of Texas, anyways, a data company, what they’re doing with it? And I just rattled through, the New York Times is doing this. And they’re like, no, no, we had no idea. Now, you need an API management layer, because then you would know who’s accessing this data. And they kind of begrudgingly launched one, and then they came back to me a year or two later, we launched a portal, and hey, you know what we found, whole new classes of users who just wanted a slice of the data, they didn’t want the entire data set, they just wanted a certain slice, to build a query, a section of it, have it in a spreadsheet and make information. And you know what, these people were ones who were willing to talk to us and give us feedback, and they’ve proven to be so valuable, so these feedback loops have been established, and it’s changing the way we’re doing the census in the future and digitizing the census. So it’s like, all right, now we’ve connected.

An example of bad: companies or institutions ask me, where do we start, we want to do APIs, where do we start? I’m like, I guarantee you’re already doing APIs, you’re just not doing it with any strategy, you don’t have a gateway or a management layer, so you don’t have any visibility. And so I had this report that I would do called Low-Hanging Fruit, here’s the low-hanging fruit. So what that meant is, I crawled their website and I looked for every page that had a table over five rows, every spreadsheet, every CSV, every XML, JSON file, anything that was data in their website, I gathered that into a list, and I would publish it to GitHub into a single README, and I said, there’s all, and I organized it by type of resource, like, here’s your digital resources, these should be hung in a gateway, you should have a management layer, and when you want to put it on the website you put it from there, if you want it in the mobile app you put it from there, and you would have more visibility. And I did this for the University of Oklahoma, and I did it for a separate group, and they never got back to me after I did the report, and I was like, okay, whatever, and I moved on. And then about a month later I get a call from their head of IT, and said, we need to talk. And I said, oh, okay, great, this is my job. He’s like, well, first, we’re gonna call the FBI on you. And I said, what, why were you gonna call the FBI on me? And he said, well, it looked like you’d hacked our systems and just did a dump onto a GitHub repo. And I said, no, I harvested all that, you’re public, I just grabbed your domain and harvested every page and grabbed every URL. He’s like, yeah, yeah, you know, when he figured that out, it took us a couple weeks to figure it out, but apparently there’s a whole bunch of spreadsheets with budget data, with PII, with all kinds of things, and people were publishing spreadsheets to public locations but they didn’t feel it was public, and they were using that to share data and sensitive data. And so we’ve taken that down, and thank you for alerting us to this. And I’m like, well, you know what, if you had an API management strategy, that probably wouldn’t be a problem, you would have a little bit more control over your digital assets and resources and what people did. He’s like, yeah, we’re going to work on that, we’ll call you when we need more help with that. So there’s two examples of large institutions that are applying API management or not applying it in different ways, and it really shows the value of doing it.

Yeah, it’s so interesting, because, so I’m currently based out of India right now, well, not based out of, but I’m in India right now, and obviously at the height of the pandemic, India being such a large country, there was a lot of things going on around COVID, and there was a lot of COVID data going in and out, and I think one of the sort of positive examples that I definitely saw there was that all of that data, whether that is looking at what’s going on in which part of the country, and India is a fairly large country with a whole lot of people, so there is a lot of data that is going in and out, and I think they did a really good job with that. The challenge, however, on the flip side of it, I’m still going to stay with us, is it’s about, a lot of the government data is still siloed inside of PDF documents, and I think that’s the big challenge. How do we move that significant amount of data, which is truly significant if you think about a billion in population, maybe, I think we were almost 1.5 billion now, that’s the kind of numbers we are talking about, and you need scalability to even support something like that at a central level, but equally there is all of the data that actually exists, but they are so siloed right now that trying to attain any kind of value, trying to extract any kind of value out of a PDF document, is a thought that I do not want to think about late at night ever.

So it is a reality. That data, probably right before that hit publish as PDF, is probably in a database somewhere that could be exposed, but it’s being published as a PDF, and then that’s the distribution format.

Exactly, and that’s the distribution, and that’s also that, you’re talking about the API strategy around how do you expose that information, because there is always hesitation, and I think that brings me to the next element, probably the last one for today, which is risk management as well. We obviously talk about growth and strategies around product-led growth or API product growth and innovation and transformation, but there is a big group of people for whom the risk management aspect of an endeavor like this is critical. So in your experience, how do you have conversations around that? How do you assure folks who are a little bit more risk-averse, but also, even if they are not, they are still going to be analyzing and trying to scrutinize what’s going on and what’s things going terribly wrong, so how do you sort of work around that, or at least reassure them that this strategy is going to do everything that it says in terms of the growth, but at the same time we have got things in place so that you’re not going to be losing out your entire business overnight?

Yeah, this is really the API game, and it gives a lot of people a lot of anxiety, because when I tell people, hey, you should be doing APIs, with public APIs it just freaks them out, they’re like, oh, you mean we’re going to be giving away, putting all of our digital assets on the open internet for anyone to use? No, you’re not. And so API management is very key to striking this balance between access and control. And to do business today you have to let your digital assets outside of your firewall, I’m sorry, you have to allow people to access those proprietary, secret, safe, valuable assets that you hoard or develop or build, and you’re going to have to access other people’s digital assets and resources to do business. So things are coming in and out of your firewall, so you can’t hide from it, you have to be doing it. And an API gateway and then that management layer around it is how you balance that accessing and control, and do it in a way that the right people are accessing what they should, the right amount of resources, they can only access so much a day of a specific area, you can get very fine-grained and control that. And then you have reports, you can invoice them on that value exchange, you can aggregate and summarize that and report to your leadership what’s being seen and what’s being done. And so if you’re not doing APIs with an API management strategy, you’re being risky in your behavior, because these are all ad hoc one-off situations to satisfy this partner request, that partner request, this mobile app, and if you do it within a strategy, you’re able to balance and mitigate that risk. And it’s still a walk in line, you’re going to have this risk, but it’s managed risk, it’s aware, you’re aware of it, you have muscles, your teams are used to doing this, you can go from a private to a partner to a public API in minutes because your teams have the skills, they have the tools to do it, they’re not freaking out and reinventing the wheel every time something’s got to be exposed, they’re used to it. And so APIs are how you deal with risk in today’s digital business marketplace.

Fantastic, I love the term, managed risk, I think that is probably the key term here, where you’re really, like you said, you are aware of the risks and you have put in a strategy for mitigation of those risks, and like you say, there’s always going to be that fine line where there is always going to be some risk. Based on a report that we have seen, there was about a 681 percent increase in the overall API security attacks in just the last year, and I think that’s just going to keep going on the more we enter the API-first world. There is going to be a greater emphasis in the world of API security, and people need to think about that strategy. And I think the worst part, not just the 681 as a number, but the worst number was that about a third of the folks who were interviewed during that survey, they did not have an API management or security strategy at all, which is obviously not desirable, so you’re not really managing your risk, and like you say, making things a lot harder for yourself, not just for growth but even for a basic infrastructure level. So with that, thank you, that has been a fantastic conversation. To bring this to a close, I would say maybe one final takeaway into the world of API monetization, if people were to take anything away from this conversation, what would be that final nugget that you would say for people to pay attention to, the one thing that you must have in your arsenal when it comes to thinking about API monetization?

Oh man, I mean, you just got to have something that gives you that visibility into that producer and consumer relationship, because if you don’t have your finger on the pulse of what your consumers are needing and be able to respond to that and build that in and find your business alignment to that, you’re never going to be competitive, you’re never going to move forward, everything that comes along is going to derail your business or be seen as a threat. So to be agile, nimble, flexible in today’s world, you just got to have that gateway layer with a management view, you’ve got to have it. And you got to do that across not tens of APIs or just hundreds, I mean, it’s thousands of APIs now, and if you can’t do that at scale and see that and then make changes and see the value of those changes you made across thousands of APIs with thousands of consumers, and respond and react in the moment each week, you’re going to fall behind. That’s it. If you don’t have that visibility, you’re in trouble.

Fantastic, so on that note, I thank you so much, Kin, that has been a fantastic conversation. And thank you everyone who’s been listening as well, we were talking about API monetization, and of course we are talking about API-led product growth in the different aspects of it during these different episodes. So once again, thank you so much, Kin, it has been a fantastic honor to be having this conversation with you, and obviously on a personal note it’s been fantastic learning so much about the world of API monetization as well. So once again, thank you so much.

Thank you so much for having me, and thanks for tuning in, you know where to find me if you want to chat again.

All right, folks, with that, thank you so much for listening, and until next time, cheers, and take care.

Thanks for listening to this episode of All About APIs, powered by Tyk, a leading cloud-native API management platform for the modern stack. So come, empower your teams, and put your devs in the driver’s seat. If you want to find out more, visit us at tyk.io, and until next time, take good care of yourself.