If I set a variable in Request1 using pm.variables.set("name", "Postman");
I’m not able to access it in subsequent requests without pm.variables.get("name") within the same collection run
I understand this is because it is set as a local variable
I need to use pm.variables.get("name") in every request I want to use name.
But, I used the following to fetch UserId from my POST request:
const resData = pm.response.json();
const userId = resData.id;
//fetch the userID and set variable to be used in next request
pm.variables.set(“userId”, userId);
And I’m able to use this userId in all of the subsequent API request calls without the need for get (These request are part of same collection and are run at once)
I do not understand how is the behaviour varying(userId vs name) in my script
If it works for the “userID” variable, it definitely should work for the “name” variable. Is it possible for you to share a screenshot of your script tab where this variables are being set?
const resData = pm.response.json();
const userId = resData.id;
//fetch the userID and set variable to be used in next request
pm.variables.set(“userId”, userId);
In the above example, the const on the second line and the pm.variables.set are both local variables. With the same name, so please be wary of scoping issues.
You don’t actually need the pm.variables.set() in this scenario, as the initial ‘const userId’ will be available to your second request as long as you use the collection runner.
It’s also worth noting how you are using the variable in the second request. Local variables can only be used in the scripting tabs. (Pre-request and tests tabs).
They can’t be called in the body or URL like a collection, environment or global variable using {{variableName}};
While you can use local variables, its sometimes better to just use collection variables for storing these types of values.
Hi @michaelderekjones,
Yes, I’m using the “Run collection” option. I was trying to figure out how set, get works and came across this scenario.
I understand how ‘const userId’ will be available in my second request, but I’m curious why the other variable was not available and I needed a get function.
Could you please elaborate on using the same name
pm.variables.set(“userId”, userId);
Could you please elaborate on the potential scoping issues you mentioned with the variable name ‘userId’? I’m new to Postman and I’m still trying to understand the best practices.
After some testing, it would appear that pm.variables.set is not the same as just setting it using const or let.
Variables set using pm.variables are available in places like the params, body and URL.
Even though when you hover over the variable, it tells you that its unresolved, but it does actually seem to work. (Logically it is unresolved, as the local variable is only set on run time).
const and let variable are just local to the pre or test script, like in a module.
to use a variable in the request definition (url, param, header etc…) in the form {{userId}}, you must use one of the form :
pm.globals.set
pm.collectionVariables.set
pm.environment.set
pm.variables.set
in a pre/test script (mostly in pre to use it in same request definition)
as far as I know, the preceding order is used if you have the same name used for a global, a collection, an env, or a “shadow” variable. Global is masked by collection, collection is masked by env, and the last wins it all.
what I call (don’t know the exact terminology) “shadow” variable is : the fact that using just pm.variables.set(‘userId’, ‘user001’) will create a variable for the time of the run. It won’t appear in any “Variables” tab.
so far, best practice seems to be :
don’t use globals
use collectionVariables if you need to set it manuelly and it does not depends of an environment
use an environement variable when needed
prefer the last one if you only need it at run time and you set it in pre/test script
all variable set by programmation in pre/test script keep there type (array, object/string, number) BUT as soon as you’re editing one in a “Variables” tab, it just turn to a simple string. Object/Array will then need to be json parsed…