When adding parameters into the header, the description field allows you to add and save the parameter. However, when attempting to reference or use the parameter, it does not function as expected
Postman scripts do not directly provide access to the header description fields via JavaScript in pre-request or test scripts. The header descriptions are meant for user guidance and are not exposed in a way that can be programmatically accessed during request execution.
The descriptions are just strings - highlighting the string value will allow you to store that value as a variable, if you wanted to do that.
You wouldn’t be able to use variables in the description field as nothing is there to resolve the variable.
I’m not sure what your use case is here that you would need to add a variable to the description field like that - Can you provide an example of that?
The current behavior of the header description field is confusing because it allows the addition of variables or parameters within descriptions, giving the impression that they are usable during execution. This inconsistency is problematic, as descriptions can be added throughout the collection, but they do not function as accessible variables or shared data points during request execution. If descriptions are intended to hold variables, they should be consistently accessible and viewable like any other variables used within Postman.
For instance, if I use the same request across multiple collections and utilize a variable within the description field, I expect to see the variable’s data. This visibility is crucial for understanding the variable’s information, especially when descriptions are meant to provide clarity and consistency across different requests and collections.
I can appreciate the confusion here but it’s just a plain text field, you could put any string value in there, you could add code in there, it’s not going to execute the code though because it’s only string. Having the save as variable option on a field that doesn’t accept them can be counter productive so i will raise that with the team.
If you’re creating a group of common headers for requests and you’re like to have the same description in there, have you checked out the Headers Presets option?
You can create a group of headers under a specific name with a Key, Value and Description:
Thank you for guiding me toward using the header manager instead of parameters in the environment or other places—it makes sense. However, one area for improvement is that header parameters are currently static, and there’s no way to manage them dynamically through a script. This limitation means that it can’t be done efficiently if the headers need to be updated dynamically.
I’m not sure why this restriction exists, especially when other parameters can be managed dynamically. If dynamic management is allowed elsewhere, why not extend this functionality to headers as well?
Thank you for pointing me towards using the header manager instead of parameters in the environment or other locations—it definitely makes sense. However, I noticed that header values are static and cannot be managed dynamically through a script. For example, I’m using the script below to directly update the value of the x-correlation-id header:
function generateUUID() {
let dt = new Date().getTime();
let uuid = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function (c) {
let r = (dt + Math.random() * 16) % 16 | 0;
dt = Math.floor(dt / 16);
return (c === 'x' ? r : (r & 0x3 | 0x8)).toString(16);
});
// Find and update the existing 'x-correlation-id' header if it exists
let headers = pm.request.headers.toObject();
if (headers.hasOwnProperty('x-correlation-id')) {
pm.request.headers.upsert({ key: "x-correlation-id", value: uuid });
console.log(`Updated 'x-correlation-id' header with new UUID: ${uuid}`);
} else {
console.log(`Header 'x-correlation-id' does not exist in the presets, unable to update.`);
}
}
While this works well for updating header values dynamically during execution, it would be great if Postman could extend this functionality to update preset header values as well. I understand it might not always be necessary, but adding this capability could provide more flexibility when managing dynamic scenarios.
