Postman and Office 365

Over the past few days I have been playing with the Office 365 REST API’s again for various things. As such I have also been playing with the Chrome Browser extension for Postman. If you don’t know what Postman is, then let me explain.

As per their description “The idea for Postman arose while the founders were working together, and were frustrated with the existing tools for testing APIs. They felt there had to be a better language for developers to communicate about APIs. This led to the creation of Postman. Postman helps you build, test, and document APIs faster.

So now that’s out of the way, open up Chrome and browse here to get the extension.

Once installed it will then add it to the Chrome Launcher which is great for easy access. Once you have it installed we can launch it and should be presented with the following:

Now even though it looks cool, unless you know what you are doing, it may look overwhelming to figure out what to do next. If you simply just pasted an Office 365 URL in there it would run but fail.

So we need to look at how it works first. In reality you need to login into the SharePoint Site first and then launch Postman. However that does not always work, so we need to make a little change which will make the application work like fiddler does.

At the top simply click the “Interceptor / Proxy” button.

Enable it by flicking the switch.

Now we can go to a Chrome windows and access our Office 365 site collection as an authenticated user. This will then “capture” this into the Postman window and be displayed in the “history“. Now if we run the same command as before it passes the Authentication failure and display our returned data.

The User interface allows for viewing of various properties of the request, which can be found in the “Headers” tab.

Clicking on the “Cookies” tab also outlines everything from the “FedAuth” token to various other cookies used by SharePoint.

This gives us the ability to see what is going on, what is sent and retrieved, along with many properties. If we wanted to we could also change the request type by choosing the drop-down that currently says “GET“, and change it to the any of the following:

Of course the key to using this is for querying SharePoint, and retrieving the data needed. Each request can also have custom parameters added to the request.

If we wanted to modify certain aspects of the header, we can add our own “Header” values. For SharePoint work we would normally want to add the following one:

NOTE: If this is not set, you are unable to actually view the results by simply selecting the “JSON” option. It actually errors:

"Accept: application/json;odata=verbose"

If we wanted to add any other “Headers” we can either type our own or pick from the presets.

A cool feature is the ability to export the command we have typed in various language, which for us “C#” developers is great and easy way of getting our code done.

Of course you can copy the generated code and use it there and then – copied code below:

var client = new RestClient(“https://{tenant}”);
var request = new RestRequest(Method.GET);
request.AddHeader(“postman-token”, “90df7037-63e6-b881-001c-c393e7360166”);
request.AddHeader(“cache-control”, “no-cache”);
IRestResponse response = client.Execute(request);

As you can see this is a great tool, which will help while working with the Office 365 REST API services, or even our On-Premises SharePoint environments. All in all a great tool, so go get it and start playing.

Liam Cleary

I work as an Associate Director for Protiviti in Virginia. My main focus is to ensure that SharePoint can either natively or with minimal customization meet the business requirement securely. I am currently a SharePoint MVP focused on Architecture but also cross the boundary into Development and Security. I am often found at user groups, conferences speaking, offering advice, spending time in the community, teaching my kids how to code, raspberry PI programming, hacking the planet and sometimes building Lego robots.

You may also like...