Postman is a valuable tool to work with APIs, especially when testing and making ad hoc requests outside of an automated production solution. In terms of where a Power BI developer may find Postman useful, it sits somewhere between the documentation’s “Try It” functionality and a more production-worthy solution incorporating tools like Azure DevOps, Logic Apps/Power Automate, a Power BI custom connector, etc.
The ideas in this post extend an original post from Carl de Souza. Carl shows how to obtain an OAuth2 access token but does so with hardcoded values. Additional API requests use the token from the original response, but he also manually provides this token to those subsequent API calls.
The following steps assume that you are already familiar with the basics of both Postman and the Power BI API. Register for a Power BI Azure Active Directory application if you do not already have one, and it should have the appropriate scope defined for your desired tasks as well.
Add Variables
Extending the Postman technique to use variables rather than hardcoded values makes the effort more automatic and convenient. In particular, passing the access token to a variable for reuse in other API requests removes a manual copy and paste “Bearer [token]” step each time a new request is made after a prior token expires.
Ultimately, the goal is to provide an access token to any Power BI REST API request without having to manually place the authorization token in the request. Accomplishing this relies on a session variable (called temp_access_token in this case as seen in the screenshot).
To obtain this result, the first step is to create a new Environment in Postman. Then, add five variables to replace the hardcoded values seen in Carl’s original post. I’ve used environment variables so that I can use them in multiple collections, but reducing scope to collection variables would work as well.
Four variables are used in the request body to obtain the access token from https://login.microsoftonline.com/common/oauth2/token. These are local session variables only (specify Current Value but do not add sensitive data to Initial Value).
1) username – Power BI organizational user
2) password – Power BI organizational password
3) client_id – ID from your Azure Active Directory application
4) client_secret – Secret from your Azure Active Directory application
NOTE: Postman currently does not have a way to secure, hide, or mask variable values. After working with Microsoft products like Azure Key Vault, it feels so vulnerable simply storing a password in a variable. For use with the OAuth grant type = password though, session variables are a step up from hardcoding it in the body of a request. This is especially true if you use Postman for teams, and the workspace is synced. By only keeping this data in Current Value, it at least stays local.
The fifth variable, temp_access_token, is not specified manually like the other four. Instead, you will use code in the Postman Tests tab to write the access token to that variable. Tests is an area to place JavaScript code that runs after the request occurs.
Obtain a Token
The initial API request obtains the access token used in subsequent calls.
Add a new Post request to https://login.microsoftonline.com/common/oauth2/token
For Headers, add:
Key = Content-Type
Value = application/x-www-form-urlencoded
For Body, which includes the variable values within {{ }}, add:
grant_type=password &username={{username}} &password={{password}} &client_id={{client_id}} &client_secret={{client_secret}} &resource=https://analysis.windows.net/powerbi/api
What follows is the most useful part. The code here saves you from having to manually copy and paste the bearer token into additional requests.
In Tests, add:
var token; try {var response = JSON.parse(responseBody);
token = response.access_token;
pm.environment.set("temp_access_token", token);
} catch (err) { console.warn(err.message); }
The code used in Tests parses the JSON response and assigns the access_token provided from Microsoft to the temp_access_token variable.
A successful request will display the access_token and other data.
It will also write the access token to the appropriate variable.
Use the Token in Subsequent Requests
Additional requests will depend on what you want to do with the Power BI API. The common step though will involve passing the authorization header with the token stored as a variable.
For Headers, add:
Key = Authorization Value = Bearer {{temp_access_token}}
For example, I can use this setup to expand all workspace data in my tenant using the admin/groups endpoint. I only need the method, URL, and the dynamic authorization header. No manual copy/paste required.
You could even extend this method to include additional variables for relative endpoint URLs and more!
Please comment below if you have any questions, and let me know if you use Postman and find this method helpful.
[embedyt] https://www.youtube.com/playlist?list=PLyWe5-Lx84g1JrDY6Zh_dfV2oO-Cy3frl&layout=gallery[/embedyt]
Hi, David, why did I get the following error after I send the request:
‘”error”: “invalid_request”,
“error_description”: “AADSTS901002: The ‘resource’ request parameter is not supported’
Thank you so much for posting this tutorial! It works perfectly and will save me a lot of time!
Glad to hear it. Thank you!
Thank you so much David, been looking for this for ages, will make my life much easier. Great post.