Transcript: How Postman Built the World's Leading API Platform — From Side Project to 40M Developers | Abhinav Asthana, Co-Founder & CEO of Postman | Startup Project #128

Nataraj: Hello everyone, welcome to Startup Project. My guest today is Abhinav Asthana. He's the Co-Founder and CEO of Postman. Postman is an API platform that powers more than 40 million developers worldwide. We'll talk about Abhinav's entrepreneurial journey, which is not at all standard — it started from his own side projects and evolved into founding Postman. We'll talk about how Postman became Ramen profitable, and the transition of Postman from a single-player tool to an enterprise tool, and his deep philosophies on design, developer focus, and more. So if you're a founder, a developer, or someone who generally loves a great origin story of a tech company, I think this is a good one. With that, Abhinav, welcome to the show.

Abhinav: Very excited to be here, Nataraj. Thanks for having me.

Nataraj: This is the first time I heard about Postman — I didn't realize, firstly, that it was an Indian company. This was back in late 2015 or early 2016. I was working at a company called Epic Systems, based in Madison, Wisconsin. Either my colleague or his wife found through SEO that, okay, this is a tool where I can test APIs. Before that I was using a tool for network tracing, to see what your API outputs are, which is a not-so-easy-on-the-eye tool, but developers tend to use it. And then I found Postman, and I never realized that Postman was at that point an Indian company. So Postman later became, for me, the poster child for the story of, hey, you can build a worldwide SaaS company based out of India by Indian founders. Postman reflected that for me for a long while, before some of the other companies came out. So I want to start the conversation with pre-Postman Abhinav. What were you doing before Postman? Talk a little bit about what you were building.

Abhinav: Yeah. Well, thanks for being a user — hopefully a customer. Many of the companies you might have worked at, or projects you might have worked on, we would have as customers too. I would go back to that 2014–2015 era. What I was doing before was actually my previous startup — Postman is my second startup. And what I was doing at that time was what a lot of programmers were doing back then, which was building products for the mobile and cloud era. I've been a developer for most of my life — I still code and still build things. I got my first computer and started programming in Logo, then Basic, and very quickly I picked up the Microsoft stack in my school days. I caught the internet bug while I was in India, when there weren't a lot of people using it — it was still very alien technology. The computer was there, but I graduated soon to building web applications, and made a hobby out of it, for which I was actually getting paid. That was a lot of excitement for me as a school kid and then a kid in college — I felt invincible to a certain extent that you could build stuff and sell your services. Many people were building websites and mobile applications, and I would just build it for them. What I did not have back then was the experience of building a product, which is why I founded my first company. There we found a lot of enthusiasm for new, creative use cases of mobile phones. We picked up this idea of building and sharing panoramic pictures. Of course, that's a default in all phones now, but back then you could just take a picture and try to share it with others. We thought, okay, the world has to be seen more broadly, and we built a whole product for building and sharing panoramic pictures. The goal was to build a Google Street View-type thing where it's a crowdsourced community street view. When I look back at it, I think we were maybe 15 years ahead of our time on bringing VR and AR. I don't know whether VR and AR are still here, but at least at that time it was non-existent.

Nataraj: How did you pick that specific idea?

Abhinav: Why that specific idea? I think it came out of a project I had done for my college campus. I was at BITS Pilani's Goa campus, and a lot of people wanted to see the college before they came. So we took pictures of the college, stitched them together, and made a virtual street view, which was extremely popular — at some point maybe a million users on that product, because they just wanted to see where they would be going. That was a product called BITS 360 that I'd built, but it was just for one place. And then when we were looking through ideas, we thought this is something a lot of people have interest in — can we scale that?

Nataraj: My first interaction with your product was actually BITS 360. I'm from the BITS Goa batch too, so I've used it — maybe in 2008 or 2009. I remember BITS 360, but I didn't know who made it or built it. I definitely remember the 3D view of the campus and what you can do. So it makes sense that you wanted to take that and productize it for others.

Abhinav: Wow. Well, we go way back then. That was the genesis of it. We had a forum attached to it, so people could ask questions and get their answers, and at one point there were more parents on that forum than kids — because parents in India are always anxious about where their kid is going to go. I learned that building a product is very different than building a service for other people, and that's how I caught the product bug, which we eventually productized. The app was called 360 — we just took the "BITS" out of it. It was eventually featured on the Google Play Store globally; I think we had 10 to 15 million users on it at some point.

Nataraj: Were you able to monetize it? What was the exit from that?

Abhinav: Monetization was horrible. The churn rate for users is very, very high on mobile — you had to get 100 million users or a billion users. And there was this little thing called Instagram that had come out then, which we thought was worse. It did only small pictures, it didn't do the full stuff that we were doing, but it just had a lot more traction. So it didn't monetize very well. We were able to make a little business out of it down the road, but not substantial.

Nataraj: How were you making money out of it?

Abhinav: We gave upgrade packs. If you wanted an additional filter, or more resolution — the model, which I actually even incorporated into Postman in the beginning to get to that Ramen profitability you talked about in the intro. You hit a friction point, you hit a button, and you buy the product. So it was fast sales — we were making a decent amount of money, probably not venture-return money, but a straightforward model.

Nataraj: At what point did that lead to Postman? Did you guys realize you should sell it or move on to the next idea? What was that transition point?

Abhinav: Eventually I realized that me and my co-founder had different visions of the product. To me, a natural extension of this was to go into the travel space — think about travelers and other things they could do — but his ideas were a bit different. So we parted ways, it was mutual, and then I tried to figure out what to do next. For one year I just hacked on stuff, and built Postman on the side as well.

Nataraj: What was the initial problem that you were trying to solve with Postman?

Abhinav: Over time I realized that through my life, while building applications — and now building this application — while coding itself is pretty solvable, the coding loop is pretty solvable, the thorniest problems come from when things are being returned over the wire as an API call. That's where I often would get stuck. You're probably familiar with the BITS Pilani practice school system — I did my practice school internship at Yahoo, and we were building bigger systems there. I was building the front-end application, and it would often break. The problem would be that we did not really know what is behind the API that is making the application break. So that was the genesis of, hey, this is a big problem. And then I encountered the same problem at my startup, where we were building mobile apps, talking to external third-party APIs, building our own APIs. It was not just me — my team was often getting stuck. If you're building new things, the API is not ready; if you are consuming someone else's API, it breaks in different ways. So I needed a very simple tool to test it, which is how Postman came around. I did not like anything that was out there — everything was designed without intent. There was no intent to design, rather. It was like, hey, we need this button, so let's just put the button here. So when you're a new user to these things, you'd often become very overwhelmed. And I've had a design instinct ever since I started building stuff. So I wanted to build something that was simple, that is something I would use daily and would solve this problem for me.

Nataraj: Were you building Postman while building something else, as a support tool for yourself? Or was Postman something you were actually building?

Abhinav: It started out as the latter thing — I was building it as a side project. I had a lot of fun doing it. But over time it became the main thing.

Nataraj: At what point did you realize this could be its own company or its own product?

Abhinav: The realization happened gradually, because over time I realized there was a lot of pull from developers wanting more of this thing. I don't think I ever intended to build a product or a company for developers, but I also had a sense that this is something that people want.

Nataraj: Were there signals you were getting that more people want this? What were the signals?

Abhinav: More product usage. I put it up on the Chrome Web Store and it just took off. Then I got a ping from the Google Chrome team — they wanted to feature the product globally on the Chrome Web Store. This was my second mention: first the Android Play Store and then the Google Chrome Store. The response was phenomenal — people wanted more. So I was like, hey, this is something really — I didn't know where it would go, or what problems actually exist. Of course, as we might talk through, every year I found bigger things to do. That was the motivation — people were writing to me, they had long lists, they had feedback. And while the product was in its very early stage — Postman today is very different from where it started — there were certain core things I think I got right in the beginning. My co-founders, who eventually joined me, were also Postman users, so they were using it a lot too. We all had this intuitive sense that once we build something and improve it, it is helping us. But when the response started coming in from the outside, that was the first clear signal that this could be big.

Nataraj: Talk a little bit about that first monetization. Developer products are notoriously hard to monetize — most of them are open source, and they have to convert into a closed-source enterprise offering before any meaningful revenue can be made. How was that journey of making it Ramen profitable?

Abhinav: I had a lot of experience with that, because I basically also had to do this — I ran out of money in life. In the first company we were doing well, but not so well; rent is expensive. I had to try a lot of models. First, companies wanted to sponsor the project, and I was very clear that I don't want to do advertising within the product for someone. So they would just sponsor the project, and we tried that. Then I tried offering a premium sponsorship for customers — that if you want me to keep going, you could sponsor this. But eventually, as you said, there was no monetization — people like to use stuff and didn't want to pay for it. The first model that clicked was more of an upgrade on the automation testing side, that people wanted to automate workflows. I priced it very low, which was a mistake; we corrected that later. And then enough money started flowing that we became Ramen profitable, so to say, where people were buying the pack — it was an upgrade pack. Then they started buying it in bulk, and that was the big aha moment: to recognize that this is not an individual product, it's actually a product that could solve a problem for teams and eventually for enterprises. That was the dividing line — developer products, as much as they monetize with enthusiasm, it's the ROI that you have to quantify and sell to their bosses. We started building product with that intent in mind: there is the developer side that would always be free and open — and we have continuously built more free stuff over the years — and then, when it comes to their managers and the enterprise buyer, that's when they want to show value, and then we'd monetize.

Nataraj: At what point did you see that this is not just a small business but a venture-scale business, and raise outside money? Did you consciously avoid raising outside money? Because I think you raised big rounds, as we see today — like a six-month-old startup raising a $10 million seed or something like that.

Abhinav: I don't know how I would do it today, but I was very conscious of raising money. Because Postman had a steady source of revenue, plus we were hackers building stuff, it was easy for us to see what we were building. So there was no catalyst for going out and raising money. We had a lot of inbound — in fact, all our own rounds were inbound through our growth. The way VCs found out about us was that their portfolio companies were all using Postman. So they started reaching out to me, curious about where we were going. Eventually I did want to start this as a formal company, and our seed round happened pretty quickly, which was rolled into a Series A.

Nataraj: Before raising outside money, was it a formal company, or just a project you were running? How long was it just a project?

Abhinav: It was just a project. When I was doing it as a side project, that was a bit longer. But once I started on it full time, and my co-founders joined full time, that period was pretty short — maybe three, four months, at which point things were happening quite fast and in parallel. We got our check and we were like, okay, now we've got to register a company, because you've got to get a bank and put the money somewhere.

Nataraj: Talk a little bit about the whole enterprise journey and selling to enterprises. At what point did you realize, okay, now we have to market and do go-to-market? Because you had this nice thing very few companies have, which is inbound traction. When you have inbound traction, at some point did it change to, okay, we have to do outbound now and find actual customers, pitch them? Or was it always organic inbound?

Abhinav: The hard part started after raising money. One of the things we were already testing out, which did require outbound effort and customer validation, was that we knew app upgrades are not a sustainable business on their own — software is never finished, you keep doing things. What we wanted to see was: can we solve a bigger problem with the product? That problem centered on how teams work together — how they work together on APIs or API-related workflows. We had some signal from customers wanting something like this, but they often were not able to articulate their real needs, the ones they would actually pay money for. So we ran a beta program, tested a bunch of hypotheses, tested price points, and eventually found out that this is a real product for teams. Before we went to the enterprise product, we ran product validation cycles, built the product, tweaked it hundreds of times, and eventually became much more of a monthly and annual business. We had that learning going in, and once we had it, my intent with our VC round was that we have to get to the US as quickly as possible to build a category-leading company. From my prior experience, I was very sure you cannot do that sitting in India, because you need customers who are best in class, at the cutting edge of technology — you need their feedback. While today's product might be good, tomorrow's product might fall behind. There were other companies out there; in fact, a lot of companies tried to acquire Postman back then, and I said no to all of them. While they were ahead on venture funding and brand recognition, we were very intent that we have this solid base that deserves more. And that's when I moved to the US.

Nataraj: What made you think, I shouldn't sell, and continue? What was the conviction? After building so many projects and seeing the organic traction — was that giving you confidence? Why would you not sell?

Abhinav: Once you know you're solving a hard problem, that nobody else is looking at it the same way you can see it, you know you have something unique. If we knew somebody else was doing something similar, slightly different, then you feel competitive pressure. But we were in a market of one, where people were telling us things they just could not get anywhere else. Most API products were actually only designed for the enterprise buyer — they were designed for the CIO, the IT department — and developers were actually just dissatisfied with whatever tooling they had. There were companies like Apigee back then, and MuleSoft — they're both part of Google and Salesforce respectively now — but developers were not using those things. So you could see that there is something here, provided we actually take up the challenge and solve hard problems. Both of these things were motivating. It was not like the job was done — because if the job is done, then you might invite competition. I knew this was a hard problem, and if the best engineers in the world are asking you to build something, you better do it — and you could do it on your own terms as a company.

Nataraj: Once you moved to the US, how did things change? Talk about the challenges for an Indian founder who started in India, moved to the US, and built it there. What were some of the interesting challenges you faced?

Abhinav: First of all, nobody knows who you are. It's true for anywhere you move — the Bay Area or something — but literally nobody knows who you are. You don't have common university friends or common connections. Even people who move to the US do their master's — I didn't do a master's here, so I didn't have that network to lean on. We did have our investor, who was very helpful in getting connections done. I started with a basement co-working space here, with a single desk. I crashed on my friends' couches, as long as the welcome was there. But the core bit was to get a relationship with customers started here. We had our first VP of marketing, a DevRel person, a support person, and we did our first event within a few weeks of me coming here. That was the start of building those relationships. Any customer who was willing to meet me, I would go meet them. I did all the support calls myself along with my co-founders, and if support opened up an opportunity, I would go meet those people too. Over time I got enough conviction that there's a lot of value in meeting customers here, and it eventually translated into hiring salespeople and customer success people.

Nataraj: Is the team split between India and the US, or is it just the US? What's the team structure right now?

Abhinav: It's pretty global. We have more than a thousand people, so it's the US, Europe — I think we have people in more than 21 countries right now. We have offices in the Bay Area, New York, Boston, Austin. Pretty global at this point. Engineering is global as well. It used to be that India, at least starting out, was much more of an engineering presence, but we have all types of people everywhere.

Nataraj: When you first moved and started doing all this outreach to customers, which couple of things really helped build momentum for Postman — both in terms of marketing and go-to-market — that helped Postman compound from that initial traction?

Abhinav: The hardest thing in the beginning was making sure that how the product is iterated on stays in sync with what customers demand, and also in line with the vision we wanted to build toward — this enterprise-scale API platform. The things that helped us compound were just solving those problems. When you're in different places, communication challenges and cultural challenges were big challenges. You moved here, and then your team is 12 hours away, and they don't understand anything you're saying. How do we actually build trust and systems to continue iterating fast? I was very sure that if iteration velocity goes down, we're not going to succeed. So what really helped us go fast was this maniacal focus that this is a problem to be solved, it has to be solved urgently, and we have hundreds of thousands — and then soon millions — of users to satisfy. That relentless focus is one thing. And then making sure operationally we're well set up, and go-to-market is evolving as we're evolving. We started with a head of customer success, built the support that enterprise customers would eventually need, and then eventually hired sales to scale more on the outbound side. All these things were happening, while product iteration and velocity also had to be very fast.

Nataraj: Are developers as customers harder to serve? How are they different from regular customers?

Abhinav: I don't think anyone in their right mind decides to serve developers. When developers choose you, you decide to serve them. That has stayed true. You cannot tell developers what to buy or what to use. It's very hard as a segment, because some part of a development organization in enterprise customers is also your competition — they're trying to build, trying to solve, if you're solving a legitimate problem. You always find competition. I would often find people who even looked like me, or were in similar positions at other companies, also building something like Postman. So you're also asking them to get rid of their baby a little bit, which is always hard. Pricing is hard. So you have to build competitive advantages on problems they are not going to solve for. Developers, while they're excited about productivity gains from tools, don't care about quality, reliability, and security as much in their side projects as in their main job. Those are things to differentiate on. Eventually you have to earn their trust so they want to use the product, and then you have to show ROI to their managers — and that's how you get a platform.

Nataraj: Over the last couple of years, building APIs or consuming APIs has become very easy, in some sense. A lot more non-developers are consuming APIs via vibe coding, or agents — with tools like Replit, or VS Code itself, which is now slightly more agentic. So non-developers can do things they were otherwise not doing, and developers can do a little bit more. How did that change the consumption patterns of Postman?

Abhinav: The interesting thing for us is that we've always known, since 2015 whenever we started, that non-developers have been using APIs for a very long time. You would often qualify developers between what we call an "inner loop" — developers writing code and using APIs — and an "outer loop," where you have all your other functions: SREs, DevOps, support functions, integrators. And then you go broader, to business users who want to get data or do something with it. The thesis in the company of building a platform was that there are going to be net-new builders in the world. That, by the way, was also one of the reasons we win among our customers — because developers would often design products just for developers, they would not build it for non-developers. So all of this has been net positive for Postman. The more developers, the more new types of developers, the more APIs they consume — which means more demand for APIs, which means more Postman usage and more Postman customers. With the rise of agents, what's been interesting is that over the last 18 months we actually treat agents as a new class of API consumers. They are as important, if not more important, than human developers for Postman. So we've been building products for them: how do agents consume APIs, what guardrails do they need, how do they do discovery, how do they understand APIs — all much more relevant, and we believe it significantly expands our TAM. A lot of the existing principles still apply. So we're seeing a mix of developers who were building applications before, new types of developers empowered by coding agents, and then agents themselves, who are big consumers of APIs.

Nataraj: Do you see the use cases Postman is used for increasing or decreasing, net-net? And is it because people are creating more APIs or consuming more? What's your thesis there?

Abhinav: It's increasing for both of those reasons. Every technology wave or platform shift results in more APIs. The way mobile and cloud were catalysts before — in fact, it's happened every 10 to 15 years. When the internet came around, we were building desktop apps, and now you have web apps. Then the mobile and cloud era started, and both led to more APIs, because now, instead of building one application, you had the client-server architecture, and now you're building more APIs for your mobile phone and multiple platforms. On the cloud side, you had more microservices and serverless architectures. As I studied the last 70, 80 years of computing, every time there is a new platform change, there are new APIs. The same thing is happening with agents — you have MCPs, you have CLIs, you have AI APIs, and they all have interesting consumption patterns. The applications developers are creating today are different than before — you're building probabilistic applications, these agents, and you need to test them a bit differently. But all of those agents also need all the existing infrastructure we've built. So we're seeing many interesting patterns, evolving every month, but APIs are the bedrock for all of these things.

Nataraj: One of the reasons I ask that question: if tools like VS Code embed things that are now capable of calling an API, taking the result, and interpreting the result, does that reduce the reason why either agents or developers go to Postman?

Abhinav: Not really. That has always been a narrow use case, and Postman's platform is much, much broader than that. In fact, we provide VS Code extensions, terminal tools, and we also have an MCP server you can connect to VS Code. Eventually you have to get API documentation, you have to get context, you have to test verifiability — not just for that one call, but for the millions of calls that are out there. The way we look at agentic development: whether you look at prompt-based development or purely automated development, what are the places you'd want to integrate Postman into your workflow? The same pattern applies. Even if your API calling is less, you have to do more context management, more discovery on the other side. Postman is a full platform today — we do everything from design, development, testing, monitoring, cataloging, developer portals, SDKs, you name it, from development tools to production runtime tools. The benefit of the platform is that it doesn't matter where you start — eventually customers adopt the full breadth of the platform.

Nataraj: You're one of the few founders who scaled an India-based company, moved to the US, and scaled it globally. What are the pros and cons of building in India versus building in the US?

Abhinav: India has fantastic talent. We have some of the best engineers in India, and they contribute as well as any engineer we have globally. So I don't think there's a dearth of talent in India. Our office in Bangalore has grown — we got a new office last year, we're getting another office this year. The thing that companies can miss is that you want to be thinking much more from the vantage point of the customer, versus just trying to finish your backlog. Once engineers traverse that typical gap — and there aren't a lot of examples out there on how to do that — they see that gain in productivity. Oftentimes companies can resort to a much more hierarchical management structure in India; they think more headcount equals more value creation. Those are some of the cons. In terms of advantages, engineers are extremely talented, and when we have engineering cycles, you get 24-hour cycles — work is always going on. You can hand over work from here, and if you build a tight-knit team, they can finish it off by the time you wake up, and the same thing continues. There are many advantages, provided companies are conscious about culture. The hardest part is keeping people in sync — even a 12-hour difference is enough to make people get out of sync. So we've tried very, very hard, and having great leaders and managers has been very helpful to understand this particular problem.

Nataraj: Who are the companies or founders — in the Postman developer space or in general — that you really admire?

Abhinav: That answer has changed over time. When I looked at companies to learn from, it was: if I could marry the design genius of Steve Jobs with the operational rigor and smarts of Jeff Bezos into the company — these were the two people I would read about or learn from. In the more recent crop, let me think — I wish I had a better answer.

Nataraj: Does Postman have Bezos-like principles?

Abhinav: Some of them. Amazon has many principles, but we have our own — create with curiosity, earn trust, and many others to help guide us. A lot of things have evolved as the company has scaled. We've adopted a much more AI-native mindset — the company runs very, very differently. Over time we've become much more engineering-centric than even we were before. The principles have been fairly static, but their practice has changed more dramatically over the last few months.

Nataraj: How did the usage of AI change how Postman operates, or how people within different orgs operate? What's been the impact of AI?

Abhinav: If AI is used consciously — and I believe we're probably one of the few companies doing it that way, considering you hear about token maxing and all the wasted spend on AI these days — the way I started thinking about it is that the company has to change dramatically, from the top down. You cannot give AI tools to people and just expect magical results. So I had to change my own way of looking at the company first. We became AI maximalists in a certain sense: if a problem can be solved by AI, we go with that first — which means feeding it all the context, making it understand our business process and workflows, and then having it suggest ideas and options. That was on the business side. On the development side, we empowered our engineers to experiment and try out coding agents they'd like to use. A combination of that has resulted in a flatter org. Everyone is either a builder or a seller, for the most part. People are building stuff right there. We're not really debating over documents or future course of action — a prototype is better. Shipping is better than a prototype, and a prototype is better than discussion. We have high-agency individuals who practice good taste and judgment to cut through the noise. AI can cut both ways — you can create a lot of slop and noise and just get drowned out. So empowering people with high agency — I personally review a lot of things, we have agents checking what's going on, they're reviewers — we're managing probably an order of magnitude more work with the same headcount we've had since last year.

Nataraj: What are your general thoughts on token maxing?

Abhinav: I think it's just enthusiasm for the technology without an end goal. Companies got ahead of themselves — they thought intelligence is going to help their business automatically. There's this principle: when a measure becomes the target, it's the wrong measure to look at. You want to look at the outcome, and if you start looking at the input, people figure out that, okay, if that's how I'm going to get promoted, if that's how my value is measured, I'm just going to spend more on tokens. It's very easy to spend more on tokens — you just have two agents talk to each other, and you have a lot of tokens.

Nataraj: If the metric becomes the goal, then everyone is optimizing the metric and not really the outcome. Is your AI spend — I've heard stories where companies suddenly went 10x on their AI spend and had to rapidly cut back. Are you seeing that happen with your company?

Abhinav: We manage all our AI agents in Astro, which is our agentic operating system. We built it with those outcomes in mind — we started building it last year. On the business side, we manage all our agents through it. What Astro lets us do is build agents on any API or any framework, but it runs in the control plane for Astro. We can see who's using what, what exactly the workflows are that we're executing. So we have humans and agents essentially living together, and we can control spend there. On the coding side, we've been more flexible, but we are definitely measuring ROI right now. There's a definite improvement in productivity, but it's not correlated with cost — that correlation is harder. Some of our best engineers use a lot of AI but don't spend that much, and sometimes we have early-stage engineers who spend a lot but aren't getting much done. So we allow developers to choose, but we also look at those costs. I would not say we're at that point where we suddenly lost control. But the way I see companies spending on AI, there would definitely be a lot in that boat.

Nataraj: Can you talk a little bit more about Astro? How does an agent within Astro look? It feels like every company needs a version of this.

Abhinav: We believe so, which is why we built it. We were building an agentic framework before, but we thought that's going to be a solved problem with coding agents — that's not the hard part. With Astro, we actually treat an agent almost as a real employee. It has an identity. You control which APIs it can call, which LLMs it's talking to; it has a control plane as well as a runtime plane. You can start with any framework — Crew, Vercel, or any of the other ones — and then you subscribe to the Astro spec. Once you subscribe to the Astro spec, the agent is visible in Astro. Then you spin it up, launch it, launch multiple instances, and it manifests itself as a UI. Many agents we have have their own UI — they can sometimes build their own UI too. But they're also available in Slack, available as a mobile phone app. So Astro functions as that layer, and then agents can have their identity in any system where users interact.

Nataraj: Is that what led to building the agent identity Passport?

Abhinav: Yeah. One of the big problems in the industry today is that agents almost always have unfettered access to APIs through API keys. When developers are building these agents, they need data and API access, for which they obtain these API keys. But these API keys coexisting with your coding agents living next to them — as well as how much these agents can call when they're calling APIs, what permissions they have — is a huge problem today. Almost every hack you see reported in the wild has to do with API keys and API access. So we looked at it from first principles: what does agentic identity mean? From Postman's viewpoint, an agentic identity is very tightly tied to what the agent can do — otherwise an agent is only an agent if it can do things; otherwise it's an LLM. So we've built Passport as a control layer for both humans and agents. You can have an agent have an identity in Passport, and then it never actually gets a real API key. It gets access that is provisioned by your team — what it can access, when, and how much. We could see the problem very clearly when we built these Astro agents.

Nataraj: Interesting. So it looks like maybe you should productize Astro as well.

Abhinav: Astro is a product. It's there — we have early access with a few customers, and the response has been very positive. We're going to have a GA announcement soon.

Nataraj: Amazing. We're almost at the end of the conversation. I want to ask, where do you see Postman going in, let's say, three years or five years from now?

Abhinav: Just like the first decade of Postman was the API platform and a system of record for enterprises to manage APIs, Postman is now building the agent-native AI stack for agents for this decade. Agents are going to be consuming and building APIs a thousand times more than developers ever did, and Postman of this decade is going to look very different from the last decade, but built on the same foundations. We have 10 years of learnings of how complex infrastructure works, what challenges people encounter when building APIs, and they're just going to be amplified with agents. So it's not just Passport and Astro — we have our Fabric gateway that we announced, we have Fern that we acquired. Postman, Passport, Fabric, Fern — and maybe a few other things — built with purely agents as first-class consumers, is what Postman is becoming.

Nataraj: Do you have plans to go for an IPO?

Abhinav: I would not share that right now. I would say we always want to build a long-term company that is customer-obsessed, but maybe in due time we'll have more to share.

Nataraj: All right. Thanks for coming on the show, Abhinav. I've always been excited about Postman, the story, and hopefully it goes to more interesting places — and maybe an IPO.

Abhinav: Thanks so much.