Using Postman to Call the Microsoft Graph API Using Client Credentials


This blog post is to help users stand up an Azure Active Directory Application Registration, explain what permissions will be needed to added to the AAD Application Registration, how to make rest calls to get an access token, and then finally call the Microsoft Graph API to do whatever call you would like to do.


Please note, that not all permissions are going to be within Azure. i.e. If you are making a Microsoft Graph call to Outlook and would like access to a calendar using a delegated permission, and the user making the call doesn’t have access to said calendar, the call still will not work as the user does not have access to the calendar.


Also Please note that there are two different versions of the Graph API, the Azure Active Directory Graph API and the Microsoft Graph API.

In addition to that, note that the Microsoft Graph API has two endpoints right now, the beta endpoint and the V1 endpoint, do not confuse this with the v1 and v2 endpoints for Azure portal as the azure v1 and v2 endpoints are not related to the Microsoft Graph’s v1 and beta endpoints.


Setting Up the AAD Application

The first step to getting access to the Microsoft Graph REST API is to setup an AAD Application Registration.

First we are going to want to create the AAD Application registrations in the portal. For this we will need to configure the application to be able to work with Postman so that we can make the call to the Microsoft Graph API. First we go to the Azure Active Directory Blade, go to App Registrations, and then create a new application registration.

2018-03-31 19_16_00-Create - Microsoft Azure - Internet Explorer

From there we are going to want to create a web app with any name. Here I have set the name as web app, and set the Sign-On URL as the callback for Postman:, it is unimportant what the callback url is, but for our case we are using that callback URL for consistency sake. Just make sure that the callback you put down for your AAD Application Registration is the same in your postman call. This is unimportant for the grant type client credentials but more important for other grant type flows.


You will have to click out of the sign-on URL to make it check whether or not if it’s correct.

After that we have created our web app, we will want to create a secret. Please keep track of the secret as you won’t be able to see the secret again. You will have to press save in order for the secret to generate.



With this information in hand, we will be able to move forward and connect to this AAD registration. But without the correct permissions we won’t be able to get an access token to make calls to the Microsoft Graph API.


Finding Which Permissions We Need for a Microsoft Graph Call

Assuming we would like to have granular control on what the AAD Application registration has access to and what it doesn’t have access to. We are going to want to make sure that the AAD Application registration only has the permissions it needs to make the MSFT Graph API calls that we are wanting to make.

There has been a separate blog post on finding the correct permissions for your graph API call listed below :

Finding the Correct Permissions for a Microsoft or Azure Active Directory Graph Call


For this client credentials flow, we will want to set the required permission for Read all users' full profiles under Application Permissions. If you check the delegated permission you won't get the correct permissions because the client credentials flow only gets the application permissions. This permission is shown below.





Accessing the AAD App Registration and Calling the Microsoft Graph API


Now lets get a secret for our AAD Application registration by going to the keys blade and adding a secret. Please make sure to keep track of this key as you will not be able to retrieve it again once you leave the blade.




Be sure to press the save button in order to see the value after putting in the description for your key.


Now our AAD Application registration is ready to go and we can utilize postman to get an access token using the AAD Application registration to use the list users functionality in the Microsoft Graph API.


Please keep track of the client id as well which is the application id for your app registration. This is shown below.



We are going to want to get our token and authorize endpoints, we can find this next to the new application registration button in the App Registrations blade shown in the picture below.




Now we can go to our postman to try to get an Access token. Below is a screenshot of how the postman should be setup with the variables we got from the steps above.


We will use the token endpoint as the URL to post, we will then add the client id, client secret, resource, and grant type in the body of x-www-form-urlencoded fields.


The only item that isn’t gotten in the steps above is the resource which is different depending on what you’re trying to access. Here we are trying to access the Microsoft Graph which is you will need to look through your respective documentation to find what the resource url is for the resource you’re trying to utilize if it’s not the Microsoft Graph.




After this we have now received an Access token back from the token endpoint for your Azure Active Directory tenant. With this access token we can create a new request with a single authorization header and the list user calls to the Microsoft Graph API.




We to have a header with the value as "Bearer <access token>" with the key “Authorization”.




We have now gotten the list of users from the tenant that the AAD Application Registration.




After going through the steps to create an AAD Application registration, finding what call we want to make, finding what permissions we need to make the call and then getting all the configurations we need to get an access token from the token endpoint. We were able to get an access token from the token endpoint and then make a call to the Microsoft Graph API with our access token to list the users in our tenant. I hope that you can utilize this flow to make the other calls to the Microsoft Graph API. If you have any issues feel free to open a support ticket and one of our support engineers will reach out to you as soon as possible, please be sure to have a fiddler trace of the error that you are experiencing.

Comments (16)
  1. Arun Manjila Purushothaman says:

    Hi, Thanks for the great post.
    I was able to get through all these steps successfully and got until /me or /users working.
    But how to get the calendar working with the same access? How do we map from Azure so that the User1’s events are accessible?

    1. Hello, I’m following up on this : “how to get the calendar working with the same access? How do we map from Azure so that the User1’s events are accessible?”
      That requires you to put the correct permissions on the AAD Application. For more information on that please go through this document :

      That being said, the calendar is in Outlook, which requires different permissions as, there are two layers of security. AAD’s authentication, but then you have to make sure your account has the proper permissions on the outlook side to look at the calendar otherwise you will receive an access denied error.

      As the client credential flow only allows application permissions, you might not be able to access the calendar as it may require delegated permissions on behalf of the outlook user.Please file a support ticket with O365 Developer for further help on this issue.

      1. Arun Manjila Purushothaman says:

        Thank you for your response. Yes I do have the required permissions from the AAD app.
        How to provide access from the outlook is my challenge, I do not see anything in the settings at the same time MS Graph explorer is able to do all the actions on calendar as well.

        1. Sure, so that means that you have all the right permissions on AAD side, but you will need someone with Outlook expertise to get it working properly. Again, I suggest to create a support ticket with outlook to continue debugging this issue as this will require some more digging to get this working properly.

          1. Arun Manjila Purushothaman says:

            The issue was resolved when I used the O365 business account with Azure delegated permissions.
            The same settings were failing over even though it was working from graph api, only failing was authentication issue between postman and outlook, couldn’t resolve that part.

            Thank you for all you great blogs, which really gives clarity and confidence to approach, keep sharing.

          2. Great! I’m glad that you were able to resolve the issue. I appreciate your feedback, and thanks for reading the blog.

  2. Oliver says:

    Hi Frank

    Thanks for the informative and useful article. Hopefully you an help me – I am unable to upload a file using a valid access token (the token allows me to list groups, drive items etc.). The error that appears is:

    “invalidRequest: One of the provided arguments is not acceptable.”
    Using the following PUT request:{my group id}/drive/items/{my item(folder) id}:/test.txt:/content
    using content type: text/plain

    I tested this exact same request using the graph explorer and my office 365 user account and the upload worked, so I though it might be an app permissions thing, however this did not work even after granting absolutely every permission to the app and regenerating the access token.

    Hopefully you can help as I would rather use an access token in my app than my user account to perform the uploads.

    1. Hey Oliver,
      I see you’re trying to use the OneDrive API documented here :

      It looks like from what you’re saying in the comment, it should work properly using Postman as well, however it isn’t.

      It looks like this would require further inspection with the OneDrive Support team. I would suggest filing a support ticket with the O365 Developer Support team, and to provide them with a fiddler trace of a repro of the issue. This process is documented here :

  3. Hi i am facing below issue, while firing get request for “” from postman, i have got the token properly, also it works if i select oAuth.
    “error”: {
    “code”: “Authorization_RequestDenied”,
    “message”: “Insufficient privileges to complete the operation.”,
    “innerError”: {
    “request-id”: “c08d8df0-1685-453a-92bf-d8f580ef65e7”,
    “date”: “2019-01-11T16:11:31”

    1. Hello,

      The reason you are receiving this error is because your AAD Application Registration doesn’t have the correct permissions. Please see this article for more information :

      and this one on understanding admin consent

  4. Shyam39 says:

    Hi, Thanks for the informative article. I followed all these steps and could successfully connect to Graph API. But how do I make to completely work from ajax, meaning make an ajax call to Postman with Client ID and secret Key and get the bearer token.

    My Requirement is to display outlook calendar events inside SharePoint. When I try to make an ajax call to “”. But this returns CORS error. Hence thinking making a call to Postman could help me getting the token.

    1. CORS error are due to the browser not allowing the request to leave the machine. This will need further debugging with a solution provider or consultant which can be found here : or through your TAM

  5. Arvin Zhou says:

    Hi Frank
    As the post, I did everything right and I am able to get token from
    But once I use the token to display all my shared calendar events, I get this error
    “error”: {
    “code”: “NoPermissionsInAccessToken”,
    “message”: “The token contains no permissions, or permissions can not be understood.”,
    “innerError”: {
    “request-id”: “4be87890-46aa-48e5-8555-6156fd582718”,
    “date”: “2019-04-11T16:47:15”

    from the portal, I set these permissions and grant them

    Microsoft Graph (7)
    Read user calendars

    Read user and shared calendars

    Have full access to user calendars

    Read and write user and shared calendars

    Read user mail

    Read user basic mail

    View users’ basic profile

    please help me

    1. Hello,

      I would suggest filing a support ticket, however it is most likely that you are using the client credential flow and your application permissions haven’t been granted by an admin. You have to be sure to press the admin consent button per the article here :

      If that doesn’t resolve the issue, please open a new support ticket and one of Microsoft’s Support Engineers will reach and help you with the issue accordingly.

  6. MLP15 says:

    Hi Frank, This post is really helpful.Can you please guide me through the steps if I would like to use findmeetingtimes API with Application Client credentials flow.Document says it does not work with app permissions but my app has delegated permissions as well allowed.When I try using postman.I am getting below error.

    Request: { “attendees”: [ { “type”: “required”, “emailAddress”: { “name”: “M”, “address”: “” } } ], “locationConstraint”: { “isRequired”: “false”, “suggestLocation”: “false”, “locations”: [ { “resolveAvailability”: “false”, “displayName”: “xxxx” } ] }, “timeConstraint”: { “activityDomain”: “work”, “timeslots”: [ { “start”: { “dateTime”: “2019-04-16T09:00:00”, “timeZone”: “Pacific Standard Time” }, “end”: { “dateTime”: “2019-04-18T17:00:00”, “timeZone”: “Pacific Standard Time” } } ] }, “isOrganizerOptional”: “false”, “meetingDuration”: “PT1H”, “returnSuggestionReasons”: “true”, “minimumAttendeePercentage”: “100” }

    Response: { “error”: { “code”: “BadArgument”, “message”: “Invalid user address”, “innerError”: { “request-id”: “929f6e29-694b-4fbc-a789-bd679403ab63”, “date”: “2019-04-22T23:15:43” } } }

    Warm regards

    1. Hello,

      the user find meeting times API is handled by the O365 Developer Team and you will most likely need to use delegated permissions to use the findmeetingtimes.
      This can be seen in the documentation here :

      Please file a support ticket with o365 developer for further information on how to use the find meeting times API.

Comments are closed.

Skip to main content