Things to consider when you use POSTMAN while calling Microsoft Graph API

Postman is a REST client for testing web services/REST APIs. It’s available as a standalone application for Windows, MacOS, and Linux and as chrome extension, it is a must-have tool for developers working with Web API. So if you’re developing a REST API or develop a client app which consumes data from a web service/Microsoft Graph API, you can use it. Also it can help you to troubleshoot issues outside of your custom application and see if there is any issue with the given API call or not. It may also help you to speed up the development.

So i thought to share the following best practices or stuff which you need to consider when you use POSTMAN calling Microsoft Graph API and securely handling the tokens with this great utility too.

  • Don’t use production user accounts because this information is stored directly in Postman.
  • Don’t use the approach to obtain access tokens in production.
    • So use it only for testing purposes.
  • If you want to run other APIs in the collection, you will need to consent the required permissions for your application.
  • If you don’t want to store user names and passwords in environment variables that sync to your Postman cloud account.
    • You can use the Get New Access Token capability to get a token without leaving Postman.
  • Getting access token and further calls to Microsoft Graph will require values like the Tenant ID, Client ID, Secret and Token strings.
    • Postman can be configured to store these values in variables and reuse them across multiple requests.
    • This is a great feature that will save you time.
  • You may see above I keep on stressing about the security with bearer token is that, if a bearer token is transmitted in the clear, a malicious party can use a man-in-the-middle attack to acquire the token and use it for unauthorized access to a protected resource.
    • The same security principles apply when storing or caching bearer tokens for later use.
    • Always ensure that your app (whatever the app you’re using) transmits and stores bearer tokens in a secure manner. For more security considerations on bearer tokens, see RFC 6750 Section 5.

Hope this helps.

Integrated experience, improvements between Microsoft Azure, Identity, Office 365, Graph API app development

Over the last several years, we’ve seen tremendous momentum of Microsoft Graph usage among developers, administrators, and enterprises. We noticed that lot of changes been made with Microsoft Identity/Azure/Office 365 platforms for developers. With these changes using Microsoft identity platform, developers now have a simple experience when building applications for any Microsoft identity—from Azure AD accounts to personal Microsoft accounts.

Few exciting changes that i noticed in recent times like,

  • An OpenID Connect certified endpoint:
    • Cool, now we now have a standards-compliant endpoint for authenticating any Microsoft identity which allows compatibility with third-party libraries.
  • General availability of Microsoft Authentication Library for .NET and JavaScript (MSAL):-
    • Now we have the open source libraries simplify the task of adding identity to your application.
    • Earlier you might have faced the complexity and now its over.
    • So your job of integration is as simple as possible.
    • MSAL for .NET and JavaScript is now GA
    • Also what i heard is that they’re going to be releasing general availability for iOS and Android in the coming months.
  • General availability of a unified app registration portal:-
    • Developers now have a single portal to register and configure all apps that sign in to Azure AD accounts and personal Microsoft accounts.
    • The new portal allows you to register and manage all applications you build on the Microsoft identity platform.
    • Now the portal is much easier to navigate and have added documentation, samples, and, tools to help you along the way.

So what’s more for developers?

  • For developers with existing applications using the ADAL library or directly targeting the Azure AD v1.0 endpoint, your applications will continue to work, and you can update to MSAL when you’re ready.
  • Now we have a shared token cache using that you can maintain a portfolio of applications built with ADAL and MSAL and single sign-on (SSO) will continue to work between them.
  • Developers are taking advantage of the many benefits that come with Microsoft Graph, such as the breadth of data available through a single API from directory information in Azure AD to mail information in Outlook.
  • While not all Azure AD APIs are currently in the Microsoft Graph, we continue to close the gap and expect to bring all existing Azure AD API capabilities to Microsoft Graph in the upcoming years as we’re heading.
    • You can also expect newer Azure AD directory features on Microsoft Graph and in some cases only on Microsoft Graph.
    • You can monitor the Azure AD capabilities that we add into Microsoft Graph in our changelog.

Hope this helps.

Microsoft Graph API – How to get properties of a file attachment?

Ok let we try to get the properties of a file attachment like its id, lastmodifieddatetime, name, contenttype, size, isinline attachment, contentid, contentbytes etc.




HTTP/1.1 200 OK
Content-type: application/json

     “@odata.context”: “$metadata#users(‘bb8775a4-4d8c-42cf-a1d4-4d58c2bb668f’)/messages(‘AAMkAGUzY5QKjAAA%3D’)/attachments/$entity”,
     “@odata.type”: “#microsoft.graph.fileAttachment”,
     “id”: “AAMkAGUzY5QKjAAABEgAQAMkpJI_X-LBFgvrv1PlZYd8=”,
     “lastModifiedDateTime”: “2019-04-02T03:41:29Z”,
     “name”: “Draft sales invoice template.docx”,
     “contentType”: “application/vnd.openxmlformats-officedocument.wordprocessingml.document”,
     “size”: 13068,
     “isInline”: false,
     “contentId”: null,
     “contentLocation”: null,
     “contentBytes”: “UEsDBBQABgAIAAAAIQ4AAAAA”

Hope this helps.

Using Microsoft Graph API to get all the rules for the given users inbox

You can use Microsoft Graph API in order to get all the messageRule objects defined for the user’s Inbox.

It’s straightforward. You can try one of the following:

GET /me/mailFolders/inbox/messageRules
GET /users/{id | userPrincipalName}/mailFolders/inbox/messageRules

HTTP/1.1 200 OK
Content-type: application/json

     “@odata.context”: “$metadata#users(’48d31887-5fad-4d73-a9f5-3c356e68a038′)/mailFolders(‘inbox’)/messageRules”,
     “value”: [
             “id”: “AQAAAI-fmCo=”,
             “displayName”: “If magic rule”,
             “sequence”: 1,
             “isEnabled”: true,
             “hasError”: false,
             “isReadOnly”: false,
             “conditions”: {
                 “bodyOrSubjectContains”: [
             “actions”: {
                 “assignCategories”: [
                 “stopProcessingRules”: true

Hope this helps.

Unlocking security insights with Microsoft Graph API

In Build 2018 conference, Sarah Fender walked through real world examples of applications that leverage the security API to help customers realize the full value of their security investments in this session.

As organizations deploy additional security controls to combat today’s evolving threats, integration challenges often limit the return of investment. The new security API in the Microsoft Graph makes it easier for enterprise developers and ISVs to unlock insights from these solutions by unifying and standardizing alerts for easier integration and correlation, bringing together contextual data to inform investigations, and enabling automation for greater SecOps efficiency.

Hope this helps.

Deva's Developer (Azure/ML/Graph/Office 365) blog!!

Create your website at
Get started
%d bloggers like this: