The Postman Console

Shamasis Bhattacharya

August 26, 2016

If this topic interests you, check our recent blog posts with updates about the new Postman Console pane and powerful debugging.

With the release of Postman v4.5 for Mac, we introduced a new feature called the Postman Console. This new feature is so exciting that Vignesh (the one who started working on it) literally renamed himself to “console”!

One of the scariest things that we had to do (and recommend others to do as well) was to open up the underlying Chrome DevTools for simple things as inspecting your requests. The console (albeit extremely powerful) was an overwhelming source of information to find the simplest and obvious things associated with daily use of Postman. Hence, we built one that is easier to use.

Here’s the summary of what the new Console in Postman is all about:

• Postman Console is analogous to a browser’s version of the developer console, except that it’s tuned for API development.
• If an API or API test is not behaving as you expect, this would be the place where you will go to deep dive while debugging the same.

The keyboard shortcut to fire up the console is cmd + alt + c (ctrl + alt + c on Windows). As long as the console window is open, all your API activities will be logged here for you to see what’s going on under the hood. I usually keep it open all the time. It simply looks “geeky” that way!

Ok, what else?

The most useful information, for me personally, is that every request is logged in the console in its raw form, replacing all the variables that I have used in a request. This saves me a lot of time while debugging the request that was sent.

Another notable feature is the ability to inspect the entire list of headers that was sent when I request using Postman. Beyond the request headers one provides, Postman automatically sends additional useful headers that your server needs, and it is beneficial to know about them. At times, knowing exactly what these headers looked like helps me debug server issues faster than if I had used any other tool.

Currently Console also logs the following information:

• The actual request that was sent, including all underlying request headers, etc.
• The exact response sent by the server before it is processed by Postman
• What proxy and certificates were used during making the request.
• Error logs from test or pre-request scripts
• console.log from inside scripts.

The last item (console.log output) is the another compelling reason why I keep going back to Postman Console. The backstory on this is very simple – I have test scripts in Postman Collections that do some really complicated stuff. And when I manage to mess them up, debugging it becomes even more complicated. But not any more, as I can now put console.info or console.warn at appropriate locations in my scripts and extract the exact line of code that is acting up. More details on how I do it is a discussion for the future. If you know your way around console.log in Javascript, this is exactly the same.

Why?

The internal JavaScript console of electron (using which Postman is built with) is available for use, then why make a separate console?

Three reasons:

1. The original console is usually a place where Postman logs its internal debugging entries. That gets mixed with console logs from user scripts, making it difficult to distinguish between the two. Similar story for network calls.
2. We recently moved to NodeJS driven runtime. Network calls from NodeJS does not show up inside Electron’s console. We needed an alternative.
3. Postman Console is specially designed to aid debugging Postman collections and API calls. Network calls are now designed to be part of standard logs. With our own console, we can design it exactly the way you want it to be.

Try it out and let us know what more would be useful additions to the console?

PS: The recently released Newman v3 (Postman CLI) also has a special way to log console information from scripts in your terminal. So, the script logs that you put in Postman will, likewise, be visible when running the same collection in Newman.