I make it no secret that I think APIs will literally shape the future of tech. APIs give us access to everything - the lights in our homes, our favorite books, the weather, inventory of the grocery store down the street. Being able to use these APIs as tools enables us to build automations and abstractions that take care of everything in our daily lives without lifting a finger.

My daily routine starts with an alarm that wakes me up within a 20-minute window at the best possible time based on my sleep cycle. I get out of bed and start brushing my teeth to some energizing music that turned on automatically after my alarm went off.

I work my way into the kitchen where the lights turn on when my presence is detected. I drink my pre-workout as an email hits my phone with the generated workout of the day. I make it over to my home gym where a catered workout playlist is already playing. I have all these conveniences follow me around my house without having to do anything. It just does it.

How does all this happen? With APIs. Not just APIs though, I’ve built this particular set of capabilities as a workflow. This happens, then that happens, and as a result, these other two things kick off.

Chaining actions together to create a workflow is where the power of APIs really shines.

Think of APIs as LEGO bricks. An individual brick doesn’t do much. But when you put them together in a meaningful way, you quickly go from a bunch of random squares to the Taj Mahal.

This is why I’m so excited about related requests inside of Postman. There were a bunch of cool announcements at POST/CON, but related requests has the potential for some serious disruption and incredible opportunities.

What are related requests?

Inside of Postman, when you add a request from a verified API to your collection, you’ll see a new little icon on right-hand toolbar. If you click it, you’ll see some recommendations of other requests to use alongside it. You can click on one of these recommendations and have it brought into your collection automatically.

I’ve built so many workflows in Postman where I add a request and think to myself, “now what?” I have to figure out what to do next to accomplish my tast end-to-end. Usually this means going back to the API spec - if there is one - and trying to identify the next endpoint to add to my workflow. But with related requests, Postman will identify what you’re working on and offer intelligent recommendations to move you along faster. These recommendations show you full documentation so you can make informed decisions on what you’re adding to your workflow.

Sometimes when I’m building a workflow I know exactly what I want to do. The hard part isn’t knowing what I want the outcome to be, but rather the steps to get there. Chances are high the workflow I’m building is not reinventing the wheel - meaning I’m probably trying to create something that has been done before.

API vendors (usually) know how customers use their products. In addition to an API reference, they regularly include tried and true patterns and best practices for using their services in the documentation. It’s often up to developers to read the docs, learn the pattern, and implement it themselves. There’s nothing wrong with this at all - in fact, it’s been a standard practice in the tech industry for years. I often refer to it as the “copy, paste, replace” method.

Related requests are taking that a step further. It sees what you’re building and offers recommendations from the vendor to get you to your end goal faster. Not only is it offering suggestions, but it’s also adding functional requests to your collections. Think of this almost like Amazon CodeWhisperer or GitHub Copilot but for Postman. Except that it’s a version trained on exclusively reputable sources with training data aimed at doing what you’re already trying to do.

Where I can see this going

I wish I had insider information on the roadmap for Postman. But I don’t. So I’m going to offer some speculation about what I see this turning into.

This initial release is step one of three:

• Create a searchable index of requests from reputable API vendors
• Update the index with cross-vendor related requests
• Unleash PostBot on the index

These are pretty big steps with a lot of implications, so let’s quickly touch on each one.

Searchable vendor-specific index

This is what we have right now. Postman has indexed collection data from verified APIs and is using it to offer recommendations for the next request to use. These collections are maintained by individual companies and generally exclusively include requests specific to them - which is a totally acceptable and understandable thing to do!

But because of this, you likely won’t be getting recommendations of how to turn on your lights after adding a request to play a specific playlist on Spotify. To do that, we need to progress to step two.

Cross-vendor collections from trusted sources

Right now the only data being indexed for related requests is coming from verified teams. These teams represent individual companies like Mastercard, HubSpot, and Momento. But what if Postman started indexing data from verified builders, like the individuals in the Supernova program?

You can’t reasonably expect companies to build and maintain collections that contain requests from other companies. But you can expect that behavior from builders. If open-source software has taught us anything, it’s that builders love finding and sharing creative ways to do something.

So if I was to build a public collection that contained all the requests from my morning routine, it could potentially be added to the related requests index. Then when you start building a collection that turns your lights on with the Kasa API, you might see a recommendation of how to use the Spotify API to turn on a playlist of your choice. This would start bringing to light clever use cases and possibly sparking new, innovative ideas in the process.

Doing this involves a lot of trust-building. Trust from Postman to individual builders. Trust from Postman consumers to the related request functionality. Open-source projects have also taught us that not everything you see on the Internet is trustworthy. So establishing the trust early with reputable builders is going to be pre-req #1.

You also need to balance priorities. Prioritize vendor collections for recommendations over community collections. Maybe the user building a collection wants to turn their lights off instead of playing a playlist next. They’d be able to do this easily if the vendor specific recommendations were at the top.

AI recommendations

Postman has been heavily investing in generative AI with PostBot. It’s a built-in companion that can help you debug issues, generate documentation, write tests, and much more. But what if we started training it on the recommended requests index?

Assuming we have verified builders contributing to related requests in addition to the vendors themselves, there’s a lot of data to train on. By then, maybe the public API network has also evolved to the point where vendors can classify themselves as different categories, like Spotify being classified as a music and podcast API, Stripe as a payment processor, and Momento as a serverless cache and storage provider. This type of context can provide an LLM with everything it needs to offer next-gen recommendations.

And why stop at recommendations? If PostBot is trained on thousands of verified collections and workflows and knows what each set of APIs are useful for, it could absolutely generate and build entire workflows automatically. We know PostBot has this capability, as it was announced at POST/CON that it can now help you build flows.

But with the power of the entire public API network behind it, imagine what would happen if you gave it a prompt of “Build me a payment processing app that sends confirmation emails to the recipient, updates a spreadsheet, posts the transaction to Slack, and plays a ’tada’ sound every time a transaction is successful.”

In seconds, you could have a flow that uses the Stripe API to post a payment, the Google Sheets API to add a row for internal bookkeeping, SendGrid to send emails, Slack for internal messaging, and Spotify for the fun sound. All you have to do is authenticate (which just got easier as well)!

Final thoughts

The game has just been changed. Related requests are a huge step in the right direction for developer experience and time to market. Knowing what to do next as instructed by the vendor is a big deal.

APIs can be intimidating - especially when it has hundreds of calls you can make. Knowing what to do next might only be intuitive to the developers of the API, which makes it hard to consume. Back to the LEGO analogy, if you dumped all the bricks out from a set into a big pile and told someone to go build it without any instructions, they might look at you in disbelief. They’d try, fail a few times, try again, and maybe get it eventually. But if you give them the instructions, chances are good they’ll come out the other side of it with what they wanted.

This is what related requests are doing for builders! They’re providing clear instructions on what to do next. Once we get additional data in there for building workflows across multiple APIs and the help of an LLM, software might actually be easy to build 🤔

I envision a future where capabilities like this enable both non-technical and technical people alike to build what they want with minimal effort. What a time to be alive!

Happy coding!