Best solution for generating and storing access token using newman

[michaelderekjones (Mike Jones)]

Environment variables can be set and changed in Newman.

I’m assuming the method you tried was running the collections with separate command lines in Jenkins.

The variables will not natively persist between the two Newman runs.

However have a look at this post by @w4dd325

250 collection runs per month on Professional?

Hi @heamshrij Say I have request 1 that, in the test tab, picks a nationality randomly from an array… I then ‘set’ the value to an environment variable. [image] And I want to use this value as a param in request 2. I could do that by calling the environment variable in the second collection. [image] However, you would also need to use the ‘–export-environment [path]’ option, as without this the ‘initial value’ would remain static. (current value is not shared with postman servers so it wo…

There is a way that you can run your first collection in Newman and export the environment to be used in the second.

As all of the info is in the same collection, I wouldn’t recommend running the Newman command line twice. Have a think about the structure of your collection.

If your collections are in a folder, you can put the authentication in the first folder. You should then be able to save it to the environment variable which can be used by requests in the other folders.

All of my collections use Environment variables for the more confidential stuff like client secrets.

My authentication keys are generated each time (as its not a problem for my scenarios) and they are also saved to the environment.

If you have a long lived token which you don’t want to keep changing then you might want to consider storing it somewhere else in something like a keyvault and retrieve that instead and send it in the Jenkins pipeline using the appropriate Newman command line attribute.

This is easy using Azure Pipelines and Azure Keyvault. You can create a separate Azure runbook (using PowerShell) to check the token expiry and update when you hit a particular trigger.
I also use the same keyvault to store the client secrets as I don’t want those saved to the Postman cloud or our code repository.
It might be slightly more challenging using Jenkins.

Best practice\best solution is subjective. It’s really down to whatever works for you based on products and skillset. I’m fairly proficient with PowerShell so Azure Runbooks are a good solution for a lot of situations for me. It might not be for you.