Monitor does not see variable's initial value got via Postman API

Ask the Experts and Postman Tips
, , , ,
1

Hello,

My question is, is there a way to reach the environment variable initial value for a monitor call, possibly without using up any more API calls inside each request? Or is there a better way for me to solve my issue, like using a text file?

Some background:
I monitor a collection and all the requests inside use the same OAuth 2.0 token. Right now each call runs the same pre-request script to generate a token and then sends the request which “eats up” 2 monitor calls on 1 request - it works but uses precious calls unnecessarily.

To save them up, I want to generate a token once and use it for all the requests in the monitor run - so I created a separate request to generate a token and save it as an environment variable using Postman API. However, the next requests see only the current value of the variable, which is empty as expected.

What I tried so far with no success:

  • unsetting and setting the same variable - works OK for collection runner but not for monitor.
  • saving the token in local, global and environment variable.
  • looking up similar problems in this forum.

Thank you in advance for help and tips.

1 Like
2

Would you mind sending a screenshot of your current implementation? This is definitely something that can be done, I’m curious to see what your setup is.

I outline how to do this via a pre-request script (run once, don’t run again until JWT is expired) in this post:

1 Like
3

Sure! Right now I am working on a simpler collection, kind of a proof of concept:
image
The to-be collection has 20+ GET requests. Tests are trivial, checking only if the status is 200 since it is only a health check.
Here is the PUT request, to update the selected environment:
image

Its pre-request script is adapted from This gist shows how using the pre-request script in Postman, a new Oauth-2 token can be obtained using the a refresh token · GitHub and generates a new token each time, works good for me so far (but I would definitely need to study the article you provided, I only had a glance before).

The most important part is:
pm.sendRequest(getTokenRequest, (err, response) => {
let jsonResponse = response.json(),
newAccessToken = jsonResponse.access_token;
console.log({ err, jsonResponse, newAccessToken })
pm.environment.unset(‘accessToken’);
pm.environment.set(‘accessToken’, newAccessToken);
});

I tried to use newAccessToken only but then the request updated me only with literal “{{newAccessToken}}”. Now, I would have only a current value in the environment.

In the request body, I reuse this accessToken value like this:
image
(I need to repost all the other env variables or else they are unset/deleted but I can live with it for now).

I send this request, get 200 and the updated environment variable looks like this:
image
The initial and current value are now the same, I checked.

The next request reuses the accessToken variable:

image
image1315×200 10.2 KB

But it returns expected 200 only when current value is not empty, which is not a thing when running in monitor mode. Initial value is ignored and can contain anything.

Now I am wondering if I saved the token as a global variable and use this global variable in the request body, would Postman consider this updated env variable “untouched” and then get the initial value instead? … I will check it and let know here how it worked.

Also, thank you for the article, I need to consider it when this flow does not work out :slight_smile:

4

Just checked this:

Now I am wondering if I saved the token as a global variable and use this global variable in the request body, would Postman consider this updated env variable “untouched” and then get the initial value instead? … I will check it and let know here how it worked.

Now the environment variable has only the initial value, no current value, and the next request gets 401 - both sent as a collection and monitor call.

5

Hi, I have the same problem. Have you found any solution on how to authorize requests in the monitor?

6

Hi Justyna, I can authorize the requests all the time, at least for client credentials token type, just wanted to make it more efficient. Frankly, I did not succeed with this optimization and we settled up with staying with the current solution.