Conflict of same variable in collection and environment scopes

Hi Postman community,

I run into a problem of having the same baseUrl variable defined in both environment and collection scopes. The environment value is something like https://example.com while the collections scope values are like /api/foo or /api/bar.

I wonder if there’s a way to avoid such conflict? i.e. explicitly addressing the scope such as {{pm.environment.baseUrl}}

Environment variables are a narrower scope than Collection, so if a variable exists in both places, the Environment variable will win.

In scripts, you can call the variables directly, by pm.environment.get or pm.collectionVariable.get, but you can’t do this in places like the URL or body where you just call the variable by its name enclosed in curly brackets {{variableName}}.

If they contain different data for different purposes, then I don’t think there is anyway around this apart to rename one of your variables.

It looks like you need to refactor your requests. One of your variables seems to be the host, and the other variable is the path. So maybe split the variables accordingly.

In my case the collection variable baseUrl is created by Postman after importing an OpenAI specification, while the environment baseUrl variable already exists in multiple environments. I’m not sure if there’s a way to change the collection variable name before the importing, and it doesn’t feel good to change the environment variable.

Another point is - as the explictly scoped variable is supported in scripts, why not supporting that everywhere when a variable is used to make it more consistent?

I don’t know the technical reasons, but I guess you could put in a feature request on the Postman Github.

I’m still not getting the variables though. /api/foo or /api/bar are not baseUrl’s. They are paths, which could be part of a baseUrl, but would not make a full base URL without the host and protocol.

Is it your environment or collection variable set this way? I’d be surprised if importing an OpenAI specification would generate a baseUrl this way.

In a pre-request script, you can use pm.request.url to return a object with fields protocol, host, path, and params.

You can overwrite those elements using the following…

pm.request.url.protocol = "https";
pm.request.url.host = "postman-echo.com";

You might be able to create a pre-request script that takes both variables and then sets the URL as a workaround.

Thanks Mike, the workaround you suggested works for me. Here’s the pre-request script:

pm.request.url.update(`${pm.environment.get('baseUrl')}${pm.collectionVariables.get('baseUrl')}${pm.request.url.getPath()}`)

Btw, here’s the OpenAPI specification: https://ea1.aconex.com/api/package-management/docs/openapi/package-management-api-v1.yaml. After imported, a collection variable baseUrl=/api/package-management is created.

I’ll raise a feature request later.

Cheers.

1 Like

Submitted feature request: Explicitly scoped variables in URL · Issue #13128 · postmanlabs/postman-app-support · GitHub