Abhinav Asthana on How Postman’s Acquisition of Fern Enhances API Documentation

Hey guys. Thanks for the throw. We're here with Abinov Astana, who's CEO of Postman, and we're talking about an acquisition they made recently of an outfit called Fern.

That well is gonna help everybody hopefully create better API documentation and SDKs. Abinov, welcome to the show. Thanks for having me here, Mike.

So, walk us through a little bit, what is the problem you guys are trying to solve here? And, um, you know, documentation I feel like has always been a problem, but hey, some people are thinking it might even get better in the age of ai, but what do you think the issues are and what are we gonna do here? Yeah, so we've been spending a lot of time with our customers.

Mike, you know, Boman is now a full, uh, API platform. We cover everything from design to collaboration, to testing to monitoring. And I think one of the recurring themes that I was hearing from our customers was that they still are not satisfied with, uh, their developer portals that often come bundled in with their existing platforms.

And, uh, you know, when we looked at the market, we saw that the phone team had done a fantastic job of, you know, both SDKs, which allow developers to consume an API. And lately they had expanded into the dev portal space and they were getting a lot of traction with the likes of Square, um, and, and Twilio and a bunch of others. And, uh, we thought that, you know, this could be a great, uh, win for Postman customers and a great thing for foreign customers as well as the whole market for these two companies to come together, where Postman, uh, offers a fantastic developer experience to build those APIs and share those APIs and, uh, Juans developer portal and SDK offerings help extend that, um, and, uh, you know, bring consumers for those public APIs, uh, as a service to public API, you know, publishers.

Mm-hmm. I think part of the problem that a lot of organizations have is that they have no shortage of APIs, but nobody really understands what to use them for or what it is they do, or what those capabilities are, which I think comes back to the documentation. And yet nobody really enjoys creating the documentation.

So how automated can all this get? So, you know, we've been, uh, investing a lot in, uh, uh, AI capabilities within Postman. And over time, I would say that actually the importance of documentation, as you say, has actually improved over time.

Like both for human and ai, you actually need good documentation as context, you know, whether it's a human developer or it's, uh, the AI agent. And, uh, I think creating good documentation is not just like generating whatever comes out of an LLM, it's actually also these iterative cycles or trying to understand like how an API behaves, um, communicating that succinctly, um, and then eventually like publishing it. So, uh, I think we, we will, we are are seeing like this, uh, resurgence of sorts, uh, of, uh, people wanting to have, you know, good engineering practices.

Uh, and, and some of it I think is also driven by just like this act of coding, just getting more and more like automated. And developers used to spend a lot of time like just writing like lines of code, but now when they're just like, you know, kind of hitting the generate button with LLMs, what goes into generating that code becomes more and more important. So I think there are these two sides to it, like the publishing process needs to improve.

I think Postman provides a lot of that with existing AI capabilities and the rest of the tooling that we offer. And then on the consumption side, we'll see more and more, uh, uh, importance there. I think with fun, I think what they have done is create a very exciting, very, very, uh, you know, beautiful like developer experience with dev portals, like with a lot of customization capabilities, with a lot of configuration.

Uh, they have some AI capabilities embedded in that, uh, uh, uh, portals as well. And, uh, I think, uh, you know, we just, we just expect that this will, uh, you know, in the future be the default for like, you know, all a p publishers out there. Mm-hmm.

How do you envision all this playing out? 'cause you mentioned, uh, AI agents, and as I understand it at least, or I think I understand it, um, those AI agents are looking for the metadata that describes which the metadata is based in turn on the documentation. So ultimately, if we want these AI agents to be successful invoking various services and being autonomous, um, you know, for one of a nail, the horse might be lost and it all comes down to the documentation, right?

Correct. That's true. That's true.

I think, uh, what, uh, has happened over the last year is that, while I think we probably talked about this in our last conversation, is that, um, while the agents have improved in capability, they're still limited around the context window and what goes as context into, uh, these LMS and, uh, uh, the difference between like demos and working products or, uh, you know, kind of a cool hack to like actual workflows, uh, is is how you put that context together. How do you take what is available about a system, uh, especially its documentation and feed it to get like the right outcome. So, you know, yeah, I'm, I'm like a full believer in, in this.

I would say that most companies, uh, uh, you know, still have hundreds of thousands of APIs that are not documented well. Uh, some of that is due to just lack of time, but sometimes it's also just due to the legacy that's built up over time, you know, in these systems. Um, and, uh, there's still like a huge opportunity for companies to update, update them, and, and frankly, they need to like, uh, I think what I'm hearing customers, uh, say is that, you know, for people who are interested in building agents, now these agents need to talk to their APIs, so need to, you know, buff their APIs and make, make these agents, you know, functional.

Uh, so all, all of that is, is very critical for the modern age. So how many APIs do you see the average organization kind of creating and actually maintaining? And is there a life cycle to this process?

Because I think a lot of times APIs get creative and sometimes forgotten about, and, um, yeah. How should we kind of think more holistically about managing these APIs? Yeah, I've seen like everything, you know, from each developer owning, uh, you know, five APIs or services inside an organization to, I would say roughly a team owning, you know, at least one.

I think, uh, uh, every organization that, uh, you know, we work with has hundreds to, you know, thousands or hundreds of thousands of APIs. It's very, very hard to actually remove an API. It's very easy to build one.

And I think with the rise of like microservices, serverless, all this over the last like decade, you know, the prevalence of the cloud, there is just more and more APIs out there. Uh, I think with every platform shift, we also see net new APIs being created. So in the last platform shift, when people went from, uh, desktop apps to mobile and cloud, I think now we are seeing like that with ai where again, you know, people want to create more and more services.

They wanna create new form factors, uh, for agents, so they're creating more APIs there. So the net number of APIs in an organization, you know, kind of always goes up. The hard part is actually maintaining, like, uh, technical integrity of the system, ensuring liabilities of qualities of these APIs are well governed.

Um, you know, there we see like a gradation between, uh, you know, I would say technology companies who are much more prone to foster development, and they're like, yeah, we just gonna like, you know, kind of keep going, just keep shipping fast. Versus I think more traditional sectors like banking, finance or, uh, uh, uh, you know, telecom, et cetera, where depending on the amount of regulation that exists or what other constraints that are there on the industry, you know, they, they wanna make APIs a much more governed process. So, you know, in a nutshell, like, uh, hundreds of thousands of APIs at, at any sizable company, if you're a startup, like the moment you get to 10 developers, you'll have, you know, at least one or two APIs, and it just keeps on growing from there.

But the management of those APIs varies from sector to sector, depending on, you know, how, uh, fast you want to go to production, uh, and, and how regulated you, you are as an industry. We talk a lot about, well, APIs need to be managed by somebody who treats it like a product and not some sort of add-on. And that the, if you're gonna manage it like a product, well, all products have good documentation, so they have to start with the thing.

But how many folks are actually managing their APIs as a product versus kind of still treating them as some sort of random software artifact that somebody granted. Yeah, I wish I had the state of, uh, API report numbers top of mind, but we'll, you know, make sure that we, uh, uh, you know, we, we share that in the next update. Uh, I think the number of companies that, uh, mentioned their API first, I believe is like somewhere between, you know, uh, 30 to 35% is, uh, if I remember right, and what, uh, you know, API first, uh, the label qualifies them as they, they think of APIs as first class citizens.

Uh, so we categorize companies between, you know, like API first, API aware and API last. You know, I think still a lot of companies are in the API aware bucket. I think that percentage has increased over time.

Uh, many companies do treat especially like their top, uh, uh, you know, monetizable APIs or revenue generating APIs as, you know, big first class like citizens. Uh, you know, sometimes, uh, money to the tune of hundreds of millions of dollars is spent on probably just one API, uh, from there on, I think, uh, you have, uh, these monetizable APIs at the top, and then you have your services that, uh, kind of, uh, are at the bottom, you know, especially microservices where developers can spin up and, uh, uh, you know, change their architecture kind of over time. So I think that's the level of investment that goes from, you know, like very heavy to very low.

Uh, in general though, because like, you know, when you're building APIs and services, they're all connected to each other. We believe they all need to be managed in a central place, which is what we have built postman for. Mm-hmm.

Um, so ultimately we will, we all just have an AI assistant that will create the documentation for us automatically, and we'll all get better at that. We may have to maybe have another AI agent that validates the whatever the first AI agent created, but are we entering some sort of an era where we're about to have, well, better documentation all the way around, starting with APIs? I would definitely say that agents will help you, you know, with the documentation, but I still, you know, uh, I think humans in the loop are gonna stay at each step.

I think the role changes to be much more of a reviewer, uh, and, and coordinator of agents versus being, you know, like, uh, totally handing it off over to an agent. We have seen that people, you know, like don't like reading just, you know, the same type of, uh, language, you know, it, it, you know, it doesn't really, and, and the hallis hallucination problems still cannot not solve, right? So it's like the agent, if it doesn't really get the right answer, it, it doesn't have like an understanding of what is right or wrong in the first place, but it tries to please, uh, people.

So it kinda ends up hallucinating. So because of that reason, until like a more fundamental breakthrough happens, you know, humans are gonna be there, but they'll definitely be using agents to write more. They'll be using agents to, you know, uh, orchestrate more of these tasks.

I think one interesting area where I do see, uh, especially with API design and API documentation agents play a big role is like consistency, like across APIs and across different systems. That's generally been very hard where every team, every product, you know, feels a little bit different. And I think one of the areas where we are investing is in making sure that agents are available for, you know, engineering teams to deploy, to make sure things are more consistent.

Um, so I kind of feel like, uh, right now, you know, people will definitely opt to use agents in areas that they did not want to do before, you know, versus areas that, uh, uh, they, you know, that are really challenging and require like, the specific skillset that a human has. But over time, I think, you know, it'll, it'll be much more like of an orchestration of different agents working together. Mm-hmm.

Um, is there any correlation between documentation and consumption of the API we create these APIs in the hopes that people are gonna use them, but yeah. From your perspective, have you seen any trends where in the APIs that are better documented are just that much more widely used? Oh, absolutely.

I think, uh, I, I would say that I underestimated it, you know, starting out like when I was a developer, like, uh, I think the amount of time I've seen people spend on just make if, if an API is relevant, like people spend a lot of time on these activities and, uh, um, if you don't have a well-documented API, you know, people just end up creating a net new API. That's what kind of happens in engineering organizations. So, you know, part of the reason why a PS sprawl exists is that just people don't know that an existing API is available to do the exact same thing.

And we have like, you know, lots of customers who have said that they were midway through a project, the project was falling behind, and then suddenly they stumbled upon like an API or, or documentation of an API that some, some other team created. And their project just went, you know, way faster, um, with, with very critical consequences. So documenting your API, making sure it's discoverable, making sure it's available for consumers, they can actually hit the API call and actually incorporate it at all, like, relevant things.

If you don't do any of these things and you just expect, you know, people to, you know, use, uh, uh, the API on their own, I think, uh, there's just gonna fail. And even in the AI age, you see like how much effort like, uh, AI companies are spending, uh, on, on their documentation. You know, it's not just like, Hey, here is, here is chat GPD, just go figure it out.

You know, there are developer portals, there are SDKs, there are videos. A lot of work goes in in making sure that people actually eventually incorporate APIs into their workflow, and it all goes, you know, uh, it all flows back to documentation. Hmm.

So going into 2026, what's that one thing you see people doing with APIs that still makes you shake your head a little bit and go, folks, we need to just be a little bit smarter about this? That's a, that's a great question. Um, you know, I would have said that, uh, giving, uh, you know, like your entire API to agents and expecting them to figure it out is, is still kind of happening.

People are still trying to figure out like, okay, how do these agents work? How do I manage context windows? And right now people are still using, uh, APIs that they're designed for humans.

They kinda still feed it in, into, uh, agent apps and expect it to work. I think people need to focus a little bit more on how their API design, how their API architecture works. We have done that a lot at Postman, kind of as we have re-architected a lot, a lot of our platform to work with, you know, ai.

I think people are still kind of, uh, you know, trying to ignore like the API problem a little bit and expecting agents work and, and I think that's how they just, uh, uh, you know, end up having failure modes, uh, whenever they ship like agents. All right, folks, you heard it here. Our little digital world revolves around APIs and yet maybe we don't give them enough thought.

So be resolved in 2026 to hopefully fix that issue. I enough. Thanks for being on the show.

Thanks for having me here, Mike. All right, back to you guys in the studio.