Consuming REST APIs in OutSystems: Discovering Postman as the Perfect Wingman
If you haven’t heard about Postman before, it’s a platform for building, testing, and documenting APIs that helps developers simplify and streamline API development. In this blog post, I’ll share my experience exploring Postman and using it in OutSystems.
Table of contents:
- First Contact with Postman
- Exploring an Iceberg Called Postman
- Discovering the Postman API Network
- Try New Tools, Stay Fresh
First Contact with Postman
I have been a developer for almost a decade (est. 2014). I started developing in Java and changed to OutSystems in 2015, where I began developing web applications on a path to become a full-stack developer.
I was getting familiar with front-end and back-end, and soon enough, I was working with REST integrations.
Throughout my career, I worked on many proof of concepts (POCs) and projects for many companies. Many of these POCs required us to connect to REST APIs, some with custom integrations with third-party services like Facebook or Twilio.
So I had to dive into the wonderful world of REST requests.
As a carpenter needs a hammer and an accountant needs spreadsheets, developers need their tools. Tools to manage time, tools to manage tasks, tools to optimize paper, tools to test code, tools to write code — tools, tools, tools! The good news is that there are tools for pretty much everything.
So I wasn’t surprised when I first discovered that there was a tool to test RESTs.
It was called Postman.
Exploring an Iceberg Called Postman
For most REST integrations, I was able to implement and test them in the OutSystems IDE. But for edge cases, when something was missing or not working, Postman was a great complementary tool to better understand the requests, their headers, and payloads.
But as I soon realized, I was only scratching the surface of Postman.
Being the lazy developer I am, I would have only one collection and one service that I would change according to whatever API I was testing.
Digging a little deeper
Later, I started working on POCs where the customer would share a Postman collection.
I found it easy to open the collection in Postman, check the services and their parameters (what headers were needed, what filters in the URL, the response payload, etc…), and implement the REST API in OutSystems.
When developing, I’ve always preferred to get my hands dirty and use a try-and-error approach than to go through lengthy documentation scrolls carefully. I’m sure you understand.
Before discovering Postman, I had used APIs that included examples on their homepage and even a cool JavaScript to try out the REST services in the API portal. But the examples were always for very specific use cases, very customized, plus each provider had its way of showing the information.
But with Postman, the experience was always consistent. The steps were always the same, and everything was always in the same place.
REST services appear as a versatile and simple solution to communicate between different systems. A common language that a developer can use to expose and consume information. Postman appeared to support, document, and test what was produced.
RESTs, the great equalizer of services — Postman, the great equalizer of documentation.
Discovering the Postman API Network
And there I was, using Postman to consume RESTs in OutSystems in more complex use cases. Happily progressing through my career.
But once in a while, I still had to look up for services of public APIs on their respective sites. If I wanted to connect to, say, Google or Linkedin, I would have their APIs documentation spread across multiple tabs in my browser for days.
I would switch back and forth between these tabs, losing service in a mess of opened pages (I’m one of those that ends the day with 30+ tabs).
Don’t get me wrong; their documentation is good, and I might sound too nitpicky, but that’s how I am with my tools. Every developer loves finding the shortcut instead of clicking two or three times. (I admit that I have had long discussions with developers about their favorite shortcuts on Service Studio.)
The thrilling sensation of replacing a four-step operation with a simple combination of keys, turning a three-second action into an instant move. Ah, what a feeling. A developer seeks these small comforts in their work.
Fret not, for Postman came once again to the rescue of my little annoyances with the API Network.
I installed the latest desktop client version and discovered a brave new world of APIs and libraries to consume.
Postman’s API Network has thousands of collections and workspaces that you can consume. An open-source marketplace with thousands of collections shared with everyone. A buffet of APIs implemented by different people. You have your average Jane or Joe sharing their implementations of APIs, but you also have official APIs.
Want to connect to RESTs from Linkedin, Twilio, Facebook, OutSystems Lifetime API? It’s all in there, in one place! You can have an entire library loaded and ready to go. All you need to do is put your tokens or passwords on the variables, and you’re all set.
OutSystems jumped on this opportunity and posted its available APIs there, including:
- OutSystems Lifetime API
- AI Mentor Studio
- Performance Monitoring API.
I find myself consulting Postman when connecting to OutSystems Lifetime and having a quick look at what services I want to consume instead of wasting time looking around for official documentation (there are links on the Postman collection for those too).
If you are trying to use the AI Mentor Studio (a technical debt managing tool for OutSystems) for example, I would suggest you to go to the API Network and search for the team OutSystems - you’ll have a collection ready to import and use (you can access it here).

Try New Tools, Stay Fresh
I had such a fixed view of how I used Postman that it took me a while to discover the API Network. I’m sure there are still a lot of features that I’m not using, but digging a bit more, I found a whole new world of thousands of APIs to consult and reduce the density of tabs in my browser.
This experience reminded me that it’s always good to question the technology I’m using from time to time.
Look at a tool, software, or process and see if there’s a different and/or better way of doing it. Sometimes just a different way is enlightening enough.