Balaji Raghavan on Postman’s 7th Annual State of the API Report

Hey everyone. Welcome back here to Techstrong tv. My next guest is Balaji Raghavan.

Balaji is Head of Engineering a Postman, and let's welcome him. Welcome Bji to the Text Drunk tv. Thank you, Alan.

It's great to be on Text Drunk. Thank you. It's nice to have you here.

So, BJI, head of Engineering, talk to me what, you know, how did, how did you wind up? I mean, I'm not sure, is that at C-level position at Postman? Is it how, give us your, your journey to how you became head of engineering here and what that means.

I can go a long way back when I was actually in like, you know, aiming to be an academician and then ended up with, uh, Google coming for an interview on our campus, dropping out of PhD, joining Google in its early days. So I spent a good amount of time growing with Google. So like, you know, I started with, uh, when, back in 20 2004 on the Gmail team when Gmail was newly launched and then helped grow it to billion active users along with it, like rebuilding a lot of the systems, recognizing the importance of like, you know, what microservices means, why it is actually important to design those APIs, right?

Et cetera. After that, uh, have also done a startup in, you know, search, which I sold eventually to Lyft and worked as the head of, uh, right share engineering at Lyft for a little while. And then from there, uh, went to another startup in the conversational AI space named Unifor as their head of engineering as a C-level, CTO, uh, grew their AI charter, uh, charter in the last three and a half years.

And, uh, before I realized that like, you know, a lot of these SaaS companies were pivoting towards agent AI platforms, I realized that like, you know, the platforms really didn't exist at all. And to build those mature platforms, you had to start at the basic layer, which is the APIs, and then start building the layers above it. That's when I had a conversation with, uh, our CEO Abena at Postman and started discussing has, he looked at like, you know, MCP and he was very excited at the time about MCP and I realized that like, you know, postman could have come up, come out with an even better protocol than MCP given its proximity to APIs.

So that conversation then, like, you know, went into me taking this role of head of engineering at Postman, and I've been here now for six months. Wow. What a great story.

Mm-hmm. That, that's interesting how, how, you know, it transitioned into a role of postman. And it's funny you mentioned MCP with API, because you know, when the whole age agentic AI things started hitting, I had questions about, so kinda what's the difference between API calls and, and Agen AI task?

You know, I get it. There's the autonomy or, you know, autonomous nature of it, the ability to string together multiple kind of task. And then of course the MCP, it's crazy.

The MCPI, I really, I think it was December it was first announced January, here we are nine, 10 months, and you would think it's been around, it is the, you know, it's the standard. Everyone's using MCP now, even though there might be security issues and other things, but in any event, it, it's, it's become the defacto standard. In the meantime, a majority of the traffic on the internet are API to API communication.

That's right. Do you see a future where these things kind of merge? I do see a future where like, you know, uh, systems will have the choice to either like, you know, go with like a higher predictable outcome versus like, you know, potentially ambiguous paths that need to be deciphered automatically, like, you know, a quick changing landscape, especially like, you know, would benefit from, uh, AI agents.

Like, you know, looking at a small percentage of like, you know, requests and recognizing that there's a change in pattern and like starting to operate with that. And, uh, while there are like, you know, traditional systems that require pretty much like, you know, predictable outcomes over there, like, you know, AI has nothing, no, uh, no, no business. So those will continue to actually operate with like, you know, predictable journeys.

One of my friends once told me like, you know, distributed systems a you know, you don't need to bring in a distributed system if you don't need to, but like, you know, if something has to scale better and you are not able to make it scale without a distributed system, that's when you actually like squeeze in and distribute system. So AI has to have the same solution. You don't put AI everywhere where like in our traditional systems don't scale, they don't actually operate with the expectations of the business.

That's where AI basically can be a leverage, It seems. So, it sounds so commonsensical coming from you right outta your mouth. I just wish people would take that to heart.

'cause it seems like we're trying to stick AI everywhere and anywhere, Uh, at Postman. Like that's why when we do tooling, we are actually enabling tooling with both like, you know, understanding of the API, which is like the ground truth, and then AI to have like better visibility into the API, so that like, you know, you have better documentation, better details in the SDK to be able to use that API better. So making LLMs like not have the knowledge necessarily about the backend system, but like, you know, decipher it is a key component of like, you know, actually making agent workflows work better and not put like, you know, all that knowledge into the model itself.

And a lot of businesses like, you know, have nuanced business logic that, uh, only their internal systems have visibility to. They can't actually embed it into the models. Agree.

So more and more of that logic has to move towards the API, not towards the model Agree. So I do think like, you know, as a result, like this, uh, relationship between the models and the APIs will continue to kind of grow. A lot of people are looking at the low hanging fruit where the model has the knowledge, but like for mature systems, you need both maturity of like APIs and models to evolve.

So that is where like, you know, postman, ad postman, I'm pretty excited about continuing to operate with that, like, you know, uh, mindset and enabling developers to have both, like, you know, access to both tooling for predictable journeys as well as for AI journeys. Love it. Bellagio, if you, if it's okay, I'd like to turn to Postman itself.

I had a lot, I think a lot of people, most people in our audience have heard of Postman. They've made a tremendous impact over the last, you know, five to seven years. But if for people out there, maybe they've got someone out there said, geez, I don't know that I've never heard of them.

How would you describe Postman to them? Uh, description of Postman, I would say it's like a, a end-to-end API platform, which enables like, you know, two things for the developer and like three things for an enterprise. The two things that it enables for a developer are, um, collaboration and automation.

So when you take your APIs, making sure like, you know, any braking changes is validated through monitoring, et cetera, et cetera, like, you know, all of those things can be embedded in and automated into your CICD pipelines before it hits production. So Postman provides a comprehensive tool for tooling for being able to enable that in addition to it for an enterprise. The third vector it provides is governance.

So that like, you know, any use of your APIs, any, uh, evolution of your API is any breaking changes in your APIs, you have governance on and are able to build, like, you know, visibility into it as well as reactionary, uh, solutions on top of it. I love it. Now among around here at Techstrong, you know, we've been covering Postman as pretty much also seven years, maybe longer nine years, but we always cover their state of API report, which has become something of a standard and, uh, in terms of a, a good, a good peek into a good kind of, uh, judge of, of where we are in this API economy, right?

And API adoptions and, and so forth. Postman recently released its seventh annual state of the API report, 5,700 some odd developers, architects, and executives, you know, taking place. And I think that was just this year's.

Um, give us the headline first, I guess Balaji. What, what do you think the big takeaway is there? Uh, the big takeaway for, uh, me personally is that like, you know, a, people continue to struggle with APIs and while a lot of people are talking about agents and AI journeys, like, you know, the actual API evolution itself has not happened to enable many of those agent journeys.

So when I look at like, you know, just, uh, statistically looking at number of people who are aware of like, you know, CPS and our designing towards like, you know, so AI solutions versus like the actual adoption of MCP, like less than 10% of active developers have, uh, you know, actually used MCP in their, in, in their workflows, which is a astonishing number because like, you know, if you look at like the number of posts about like, you know, technology at this point, I feel like, you know, I read 80% about agent and MCP when in fact only 10% is adopted. But yet when you look at it, Hey, it's only been around for nine, 10 months, 11 months, 10 percent's pretty good. But I think, I think what's happened is, is the, the AI adoption hype cycle has gotten so overheated that we just think everybody's doing this.

Everybody's using MPC, everybody's developing or managing agents. Everyone of course uses generative, you know, and, and it bears up, you know, we see, we see other, uh, metrics surveys. 90% of developers are using ai, 40% don't trust it.

65% thinks it thinks that it introduces instability into the software base, the code base, but yet 90% use it. So the whole thing is kind of cockeyed, if you will, right? The whole thing's kind of upside down.

Um, but that's interesting. 10, 10%, Yep. In 11 months, there's nothing, nothing to, to sneeze at.

What else were some of the key findings, do you think? I mean, the other key finding, I actually, uh, I mean, being new to Postman, this is not new for Postman, but new for me, my personally, is the fact that like, you know, uh, I know that like, you know, a majority of their teams that are collaborating with like, you know, APIs and microservices tend to be under 10, 10, uh, engineers. And so that like, you know, wasn't the astonishing number, which is like 84% of our, of, uh, overall teams are less than 10 people.

What was astonishing to me is, uh, despite like, you know, so many, uh, teams being under 10, uh, several of these teams still have collaboration challenges with regards to their like, you know, microservices and a PS. So, uh, when, when you look at like raw numbers and like, you know, we did the survey to understand what are the collaboration challenges they're running into about 55% of the developers were struggling with, uh, just documentation around those APIs. And, uh, you know, about 34, 30 5% of them were struggling with discovering APIs that are already present within their organization.

So like in our, despite having several tools available in the market to actually like, solve many of these problems, including our own API platform, which solves most of these prob problems, I continue to see like in our small teams, medium sized teams actually struggling to actually like to utilize these tools very well. So I think that that is a key insight which enables me to write, like, think about like, how do I make this problem completely go away, and like if I can design better for that, like, you know, identify what, what is missing for people to be able to kind of like, you know, solve this with Postman, we will continue to invest in that direction and like, you know, bridge this gap. It's a huge opportunity because like, you know, first of all, like APIs have existed for a while, but like, you know, APIs have always been DESI designed for human consumption, not for machine consumption.

And so APIs by definition are gonna change over the next year or two years, uh, to be more machine consumable and like, you know, during that period, we have to solve not only for human, uh, like in our discovery of APIs, but also for machine discovery of a PS. So it gives us an opportunity to bridge this gap in the right way to design the right product in that space. And, uh, I'm pretty excited about that.

Absolutely. I got a couple questions on that for you. When you say teams, you, you can have multiple small teams within a larger organization.

com here, right? com and others. You know, there is that the Spotify squad sort of, you know, 10, 12 members, the, the Amazon two pizza team.

So that, that seems like the, uh, the right size for a team of engineers, right? Absolutely. It seems like a manageable size.

Um, what's interesting is even in teams of that small size communication, 'cause I would've guessed, well maybe because everyone is remote and we have, you know, remote issues. I'm on a different time zone. I'm in India, I'm in Europe, I'm in California, I need asynchronous communication versus synchronous, you know, maybe that, but that doesn't seem to be what the issue is.

Yep. Very interesting there. Um, and both of those were kind of counterintuitive too.

Like you wouldn't, you wouldn't necessarily think that. What else did you find interesting in the report? I mean, the, the positive thing that I actually was pretty excited about is, um, the fact that like, you know, when you look at, um, uh, the percentage of, uh, developers who are actually, uh, utilizing an API first development approach, like and I, that is continuing to increase, it's about 25% right now.

And, uh, several others are like, you know, partially API first. So that number is continuing to increase over time. So that's a very promising number.

The second part that was exciting for me is also the fact that 70% of those, uh, API first developers said that Postman helps them collab, collaborate with other developers. And, uh, the same population, 55% of them said that like Postman also enables them to collaborate with non-developers. So from that perspective, like, you know, the ones that are using our tooling already, it, it is clear that like, you know, we are building the right journeys for them.

The ones that are not using our tooling and like, you know, continue to struggle with API collaboration, those are the audience that like, you know, I'm, I'm looking forward to actually like getting more in front of and having discussions on like how postman can be actually helpful for them to continue on that path. Excellent. Um, on, on that front look, I, I think we both agree that we're gonna see more and more code being developed, being written or gen written is the wrong word, generated by ai, right?

The Hip. Do you think the AI generated code is going to make the AP, like incorporate the APIs and API calls into that? Or do you think that will maybe, so is, so is AI generated code gonna result in us using more APIs, the same amount of APIs or less APIs?

I, I do believe AI generated code will require more because like, you know, there are already solutions being proposed because of like the explosion of number of tools and the tool selection process in like the MCP protocol itself, uh, that like, you know, companies are recommending rather than directly using the tools, uh, to actually generate code to in, to invoke the tools. And they, like generation of code require, like, you know, will require execution through APIs, so calling APIs. So that's why, I mean like, you know, I do believe that even like, you know, an optimized solution for an agent journey started with like, you know, this assumption that LLMs will be able to directly interface with these services to then recognizing that like, you know, there is, it's a distributed system problem where you will end up with like too many services to call and you have to pick the right ones and you have limited context to do so.

So better way to solve that problem is to actually generate the code that can execute and like, you know, call into those a subset of those particular APIs. So that does give me confidence that like, you know, I will see continued investment in every company, you know, building more mature APIs so that LLMs are, have less ambiguity in how to use those APIs. Okay.

Excellent. Bola, you're, we're probably a little over time already. 15 minutes goes quickly for people who want to get a, uh, download and maybe dive into this report themselves, maybe even look at previous reports.

Where could I, I, I imagine they could go to the Postman's site. What's the URL and where can they find this report within the site? I, when you just search in Google as well for state of the API report, postman, you will always find it.

Okay. And I imagine you could ask your favorite, uh, ai ai, you Can also ask How to find it too. com/state of API state dash of dash API slash 2 20 25.

Perfect. Hey, Balaji, first of all, congratulations on the role of Postman and I think congratulations here in order to Postman for getting someone of your quality on board here, uh, heading up engineering, looking for great things going forward. You welcome back anytime you'd like, man.

Appreciate it a lot, Alan, it was great meeting you. Appreciate you. Alrighty.

Bji Raghavan, head of engineering your postman here on Text Trunk tv. Go check out their seventh annual state of API report. As Balaji said, Google it, ai it, go to the website, whatever.

Just go get it. We're gonna take a break on text Drunk tv, we'll be back in a little bit.