How Postman uses Postman: feature exploration, AI research, and custom Flows

We love hearing from our community about how you’re using Postman to improve your API development experience—it truly continues to inspire us. But have you ever wondered how we might be using Postman internally as we’re building the Postman API Platform and optimizing our own workflows? In this installment of our “How Postman uses Postman” blog series, we’re taking a look inside Postman Labs, our research and development team exploring cutting-edge innovations, to see how they’re using Postman to build Postman.

Today, we’re chatting with Sterling Chin, who is an engineer, manager, and research associate in Postman Labs. Sterling is based in Houston, Texas.

Sterling, what do you do at Postman?
I work in the R&D arm of Postman, called Labs. I’m a product manager, engineering manager, researcher, you name it—I do it all. We have dedicated designers and engineers, so my role tends to be a little bit more high-level, and I’m often interacting with other teams at Postman. I work with teams to help them implement their goals when they relate to something we’re doing in Labs. For instance, I’m currently working with a lot of other teams on their potential integration into our Postbot AI.

I joke that I’m the API for Labs. If someone has a question about Labs or something that we’re doing, it inevitably ends up coming to me in some way, shape, or form.

What were you doing before you joined Postman?
I was an engineering manager at a startup, where I built a design system from scratch. It started as a hackathon project, and they ended up liking it. They said, “Alright, Sterling, you’re going to lead this,” and I created a team. So we built the system from the ground up and then worked on implementation and adoption around the company.

Getting to know Postman Labs

What does Postman Labs do?
Over the last two years, Labs has shipped multiple new products that are being used throughout the Postman API Platform. For example, we spun up a team around adding new protocols to Postman. So, if someone wants to use WebSocket, gRPC, the new GraphQL client, MQTT, and so on, one of the teams I work with has been focused on adding multiple new protocols to the ecosystem.

Labs really is like R&D—our jobs are to create proofs of concept quickly, to validate or invalidate a hypothesis, and to get it out in front of a customer or two. We focus on the 0–1 aspect of the design and creation of a product. Once we’ve validated an idea, we continue to iterate on it, and eventually that idea will grow up and graduate, leaving Labs. At that point, a whole product team will be spun up around that idea.

One of the other teams I’m working with is Postman Flows. The Flows team developed a visual code editor for building API applications. That team started with an idea. We iterated quickly and received feedback, and Flows eventually graduated from Labs to become part of the Postman platform. Right now, we’re doing that with AI, where we’re developing Postbot and various other AI initiatives.

So, that’s an idea of what Postman Labs is. We ship a lot of products, and they usually aren’t fully fleshed out—they’re not ready for a million users. There’s a lot of stabilization and maturation aspects to consider, but those are outside of Labs’ purview.

Is Postman Labs one team, or many teams?
We’re a small team, and we’re somewhat specialized. For example, before the multi-protocol team left Labs, they weren’t completely siloed but they were pretty targeted in terms of their work. Flows was the same way due to its very specialized requirements. There is a little bit of siloing now with the AI team. We have AI researchers that we’ve brought in, and we also have full-stack engineers that are doing a little bit of everything.

So, we are multiple teams, and yet, we’re one team. We have our marching orders—someone’s working on multi-protocol, someone else is working on a specific protocol inside of multi-protocol, someone’s working on Flows, someone’s working on AI, and whatever other proofs of concept we have. And we’re located all over the world. Half of the Labs team is in India, and the other half is based in the Western Hemisphere, including Canada, the US, and Brazil.

Do you have any fun stories about your team?
We have our own Labs watercooler channel in Slack, where we share memes, tell jokes, and talk about things that aren’t necessarily related to our jobs. We get together as often as we can, whether it’s within the smaller subsections of our teams, like the AI team or the Flows team. We try to all get together a couple of times a year, and during those times, we spend a lot of time going out to eat and enjoying our time together. We like to go out to a nice meal—not a fancy restaurant, just a nice meal where we have the time to just sit and talk. There’s value in those offsite or off-topic conversations because we inevitably end up talking shop. We’ll do a working lunch, and then all of a sudden, we come up with these ideas that we wouldn’t get if we were sitting at our computers at the office.

We also play games online. Once a week or so, we’ll play Jackbox games together to break the ice. There’s value in spending time together and building those relationships. And we’re always chatting in the five or 10 minutes before a meeting starts. Those random conversations that happen before and after meetings are vital to the health of the team.

How Postman Labs uses Postman

Does your team use Postman while working on Postman?
We find that we need to have in-depth knowledge of the area we’re helping in order to integrate into it. For instance, our first foray into AI and Postbot was adding and writing test scripts inside the Tests tab. And that required knowledge of how people were currently using the testing area. What types of tests are they writing?

Personally, I use Postman Flows and collections significantly. I interface with a lot of APIs from a lot of companies right now, and I do a lot of comparisons. Flows allows me to put together an API application quickly and iterate on it without having to pull up a code editor or run local code on my computer. I can run it from any computer, access those APIs, and compare them.

We also use our own collections and workspaces to do demos. We don’t have dedicated QA embedded in our teams, so when we’re testing out a new product, an alpha version, or a proof of concept, we create our own workspaces and our own collections to test that specific item on that specific product to see if it works.

[Editor’s note: Check out these public workspaces featuring Postman Flows examples—Business Flows, Integration Flows, Natural Language Processing (NLP) Flows, Slack Integration Flows, DevOps Flows, Utility Flows, Miscellaneous Flows.]

For Postbot, we added the capability to do visualizations. Postbot can help with visualizing the data that comes back from the response. This can be hard to test when it’s a small response like a Hello World application, where there’s only send and receive. So, we needed to find APIs where the responses were massive, so that now we can iterate and see how the visualizer works with these large responses. We end up sharing those collections and forking them within the team so that anyone who’s testing something has the same type of response to test.

Was your team’s internal use of Postman a remedy for a one-off challenge, or have you implemented it as an ongoing practice?
It’s kind of been inherent. But I didn’t always use Flows, for instance. There was a time when I was using other products and writing code myself. As we iterated quickly on the product, Flows got to a point where I was able to use it regularly, and I haven’t stopped. It was like that inflection point where I decided that now I’m going to use this in my daily work.

There’s a point where the products or integrations we’re building aren’t up to snuff, or they’re not ready for widespread use. For the GraphQL client we worked on, we needed to be able to get the client and endpoints to use, but then we needed to compare that to other products and make sure that it meets the needs of our customers. And once it did, and we were able to validate it, we ended up using it regularly.

I think that’s the nature of Labs. I have workspaces that I’ve spun up for a specific project for a specific proof of concept, and then I got rid of them either because we’ve invalidated the proof of concept or we validated it, and now we’re iterating on it. And that workspace and its collections or Flows just became unnecessary. So, there are some one-off instances where we use one or two products by themselves and then forget about them. But I think overall, in our use of Postman, the two features that are extremely consistent are collections and Flows.

Did anything surprise you about using Postman to solve your problem?
Oh, it’s so much easier now. Once I got to the point of using Flows regularly, I realized how easy it was to stand up an application that worked for me without the overhead of new repos. At every other company, you have your boilerplate application that you spin up. That app will hit all the APIs, iterate over the data, hit the next API, and do a chain of all of this together. Flows was so easy to understand once I got the hang of it. And then it was completely unnecessary for me to write code or to spin up brand-new boilerplate applications when I could just easily connect those APIs.

What Sterling has learned from using Postman

Favorite productivity tips for working with Postman?
Flows. The productivity gap goes under the radar of most people who have never had the chance to use it. We have all these APIs that we use. We have internal APIs, and I have external-facing APIs like Slack, Confluence, or my Gmail calendar, and what Flows has enabled me to do is create automations and workflows for myself that I couldn’t do elsewhere. At one point, we had a waitlist for accessing Flows. It’s not yet GA, and we had people who were signing up to try it. I used a Flow to get internal feedback and set up the waitlist that was coming through our system. I pulled that list every day using Flows and used it to enable the Flows feature for the next set of users.

What’s something more people should know about Postman?
I think Flows is a feature that a lot of people have overlooked. Once you get to use it, you really start to understand the capabilities of Flows. Now, all of a sudden, you can create amazing little API applications that are tailored specifically for you. No one really understands the power of Flows until you’ve tried it.

What’s something you’ve worked on recently?
I have a Flow where I compare multiple AI APIs. For instance, I use OpenAI’s ChatGPT-3.5 and ChatGPT-4, Google Bard, Anthropics Claude, and Ollama on my machine, which creates a local API for me. I have a Flow that takes a single line input prompt and then runs it through all five of those APIs, and then I ship that to Airtable. For instance, I can ask, “Why is the sky blue?” Each one of those AIs is going to give me a similar answer, but they’re not always the same. I had a whole list of prompts and I fed it all this information, and some AI APIs gave me extremely verbose responses when I wanted one word or one sentence. So for one use case, I knew that I wanted a response that was more direct and to the point, so I made a new Flow to connect that specific API for that project.

More about Sterling

Without revealing any secrets, what’s something you’re excited about working on or exploring for the future of Postman?
There’s so much research that’s happening internally, and every AI has an API. The world is still an API-first world, so the fact that I can connect to all these LLMs through an API and then connect them all through Flows is huge. So that’s one thing I’m really excited about—everything AI and APIs.

Do you have any side projects or hobbies that you want to share?
I’m a huge Lego nerd, and I’m a space nerd. Everything related to Legos and space. I also do 3D printing, and I’m a musician. In my spare time, I’m a maker and a builder at heart. And my kids are now adopting it all, so I get to share it with them, too.

The bottom line

Sterling and the rest of Postman Labs focus on 0-1 product design—researching and testing out new ideas and features to add to Postman. Individuals on the Labs team often use their own collections and workspaces for projects and testing, which their teammates can fork for seamless collaboration. In particular, Sterling finds tremendous value in Postman Flows, which he uses to spin up custom API applications without writing code by hand.

Thanks for sharing your thoughts and experiences, Sterling!

Tell us how you’re using Postman in a comment below. Interested in becoming a Postmanaut and joining our team? Check out our Careers page.