Day 13 : postman challenge - Newman query


I could completely execute my Day 13 challenge using postman Web. All test cases passed. But I am unable to run the same using newman.

The command I used to invoke the collection is as follows
newman run --environment

Out of the two folders under Day 13 collection, ‘Newman’ folder completed successfully but ‘submit’ api is throwing
[401 Unauthorized, 575B, 262ms].

I could make it work if I set initial value of my x-api-key instead of only current value. As per the document it is not safe to add my API key value to initial value.

Could you please help?


Open in a Postman tab.

Do you see your credentials there? If not, make sure your INITIAL VALUE is the same as your CURRENT VALUE.

vdespa, As I understand it you are absolutely not supposed to persist your API key like that (just like te OP says.)

Since the 30 Days Challenge collections are public, persisting something (i.e. putting it as INITIAL VALUE makes it publicly available.) And the API key is a private credential. No?

Thanks for the replies.

Vdespa, if I expose my API key will that not become a security issue?

Can we have a more secure option?

You can use flags to specify a JSON file to use for variables in when running your newman command. It’s -e <path> for enviroment variables and -g <path> for globals. I found this out by looking at the help with newman run -h.

So if you use -g the command would be
newman run "Day 13- Newman.postman_collection.json" -g <path-to-file>

What to put in the file? You can export the variables from Postman to a file. But if the key is not persisted the variable value will just be an empty string. But you can figure out the structure from that file. I found the simplest file to be

    "values": [
            "key": "<key name here>",
            "value": "<value here>",
            "enabled": true

If you are not sharing your workspace or environment, you are no exposing your API key.

But as @devies-daniel correctly said, if your workspace is public, this is not a good approach. In my original reply, I was trying to explain why it does not work as it is.

A more secure option would be to inject these values directly to newman, using --env-var

--env-var "<environment-variable-name>=<environment-variable-value>"

Will these Newman commands still work if the collection is not public?

Yes @pamela-gilmour, they will work since you provide an API key, which authenticates you with the Postman API.

1 Like

Hello all,

I managed to validate my solution in Newman successfully, using the command below:

newman run "[path to Postman JSON collection]" --folder "Submit your solution" --env-var collection_uid=[my_collection_uid] --env-var postman_api_key=[my_api_key]

But I was wondering, is this considered a secure way, passing the value of my API key in the command parameters? Or is there something better?

I saw @devies-daniel 's reply above, where we can export the api key with the rest of the variables (if we persist them as current and not initial, I guess). Is this a better approach?

I am not saying they are not secure, just wondering so that I can stop studying this challenge (day 13) and go to the next! :grin:

@kostassav you may have misread me, or tagged me when you meant someone else. I was arguing directly against saving keys as Postman variables. Especially if they are persisted.

The reason for this is that if the workspace or environment should be public, those keys would be public too.

As @vdespa said, if your workspace or environment is not public, then those keys will be safe and it should theoretically not matter. BUT! In practice I would say that this falls under the same best-practice as committing keys to your git repo. That is, DON’T DO IT! Even if the repo is private.

1 Like

OK, I understand.

So the conclusion is, the most secure way (at the moment) to run the Newman query is by passing the key in the command, like @vdespa mentioned here?

As long as you are also masking your credentials in the logs. Most CI/CD systems will do this for you when you define environment variables with credentials.

1 Like