Base-URL in collection

[MacDisein]

It should be possible to set a base-URL to a collection. That base-URL will be use as a basis for all URLs of the request in the collection. So you are able to use the same collection for different environments by simply change the base-URL of the collection.

Each request URL may contain a placeholder (e.g. ) for the collection's base-URL.

[sdnts]

Hi @MacDisein, while I understand the reasoning behind this, I think this will limit the requests you can make from a collection to a single server. I'm curious, do environment variables not work the way you're expecting? You can add an environment variable called url and have it have different values in different environments. This should then work exactly like you said, you can use the same collection for different URLs by changing the environment.

[MacDisein]

Hi @madebysid - I am not aware of the variable feature in Postman. So you are right I can use variable together with the environment feature. Thanks for pointing my into the right direction.

I think we can close this feature request...

[logiclabs]

I think nearly everyone who discovers variables would probably appreciate not having to add {{url}} for every operation.

Couldn't this work like most language/framework Uri processing code works, using absolute and relative urls?

• if you specify an absolute url i.e. http://myhost:1234/customers/:id, it works as now.
• If you specify a relative url i.e. /customers/:id , it uses a base url (defined on collection/environment)
• If you want access a host/protocol different to the common base address in more than one place i.e. http://myotherhost:4321/customers/:id , the user can then use the current variable method i.e. {{otherurl}}/customer/:id (with otherurl defined on collection/environment)

It would be a nice timesaver, as I guess most people set up collections/environments for testing against a base address/service.

[eromoe]

What is the base url variable name ? here https://www.getpostman.com/docs/v6/postman/environments_and_globals/variables says we need define {{url}} , and write {{url}}/xxxx . But I prefer /xxx .

[rcarvalhosilva]

If there is the possibility of defining the authorization header for a collection it should also be possible to set a base url since different servers could have different authorization headers, right? So I think it makes a lot of sense to add this feature and it would help to save a lot of time. And just like we can choose to use a different token for a specific request we could choose to use another url. What I'm trying to say is: it would be nice to be able to set a default url or maybe more than one :)

[igorsantos07]

I came here also looking for a way to get rid of {{url}} in the beginning of all my requests. I'll ping @madebysid as he interacted with this issue initially and might not be getting notifications as it got closed, so maybe it can be reopened :)

[jboarman]

@MacDisein @madebysid Would you mind re-opening this issue as there are a lot of folks that share this same issue and are looking for a more integrated solution.

For one, if adding a {{url}} variable is recommended, when I import a collection from a swagger spec, then I would hope that the Base URL variable would be added to each URL for me. That said, I'd rather not have to specify the variable for each endpoint ... it should just allow relative paths with the base specified at the collection level.

As it is, I just imported a spec and have hundreds of places I would have to edit URLs to insert this variable. Very inconvenient! 😧

[joelpro2]

I share the same inconvenience. I have a server with many packages and in every URL i have to write {{baseURL}}/{{version}}/{{package}}/endpoint Instead, postman could have in folders breadcrumb, along with description, auth, ... , default URL. and it would behave like:

My collection (with {{baseURL}}/) ---->My version1 folder (with {{version1}}/) -------->My package1 folder (with {{package1}}/) ------------>POST endpoint (URL endpoint1)

---->My version2 folder (with {{version2/}}) -------->My package1 folder (with {{package1}}/) ------------>POST endpoint2 (URL endpoint2)

endpoint would call -> {{baseURL}}/{{version1}}/{{package1}}/endpoint1 endpoint2 would call -> {{baseURL}}/{{version2}}/{{package1}}/endpoint2

which is actually almost the same as what authentication do

[vinguan]

Is there a way to do this yet?

[GalvinGao]

Definitely an inconvenient for me! Using Base URL with environment feature can also allows the user to choose the environment they want to run their requests on, say using production and development, etc,. This will be a very handy feature to add on!

[a85]

We recommend using collection level variables and setting variables manually for requests as Postman can't assume that one baseURL applies to each request. I understand that Swagger/OpenAPI schemas do this but Postman can't be expected to abide by the assumption of spec formats. We expect this job to be done by converters and we'll open up plug-ins so people can write their own.

[jonrimmer]

@a85 There's a big, big difference between having Postman assume that a baseURL applies to each request and giving the user the option to set one.

[logiclabs]

I can't quite believe the reluctance to improve this as a feature.. adding {baseUrl} to every request is painful, even more so when importing large collections. I think an issue is that the original question was closed and answered correctly to use variables, and I suggested a way to improve them slightly. Perhaps this need to be raised as a new issue with a clear requirement?

Even the original HTML spec implemented a way to set the base url for relative links, without having to add any variable interpolation. This would be one way to implement (allow relative urls and a collection/env base url fallback), with a further enhancement being ability to override base url for collection/environment (i.e. overriding the base of absolute urls). This would make it easy to switch to environments for a collection imported from a particular host (i.e. override http://localhost:1234/ to https://staging.myapi.com/)

[GalvinGao]

Swagger has implemented host and basePath in OpenAPI 2.0 which has become a very popular standard of creating API documentation. Having the base URL feature embedded in the environment feature will be surely a convenient and also standard-compliant way to deal with this problem facing towards to 8+ million developers, 400,000+ companies, and 250+ million APIs :open_mouth:

[a85]

@GalvinGao Postman is integrating specifications more tightly so workflows based off specifications will flow more naturally. Putting a baseURL in the collection format specification is a different issue though.

[sirwolfgang]

@a85 To clarify, what do you mean by "more tightly"?

[routinet]

We recommend using collection level variables and setting variables manually for requests as Postman can't assume that one baseURL applies to each request.

@a85, I think you misunderstand the feature request. The comment posted by logiclabs gets this job done, and conforms to other behaviors already found in Postman.

For example, when creating a collection, I have the option of setting an authorization regime. If I do, that regime is, BY DEFAULT, propagated to any requests created in the collection. In each individual request, I have the option of overriding the authorization regime, or removing it entirely. The simplest example is creating a collection with no authorization, then adding it to the specific calls which require it.

Likewise, it would not be difficult to have an option to allow me to specify a default base URL for a collection. In each request, I obviously have the option of overriding it.

While I realize we can currently use variables to simulate this behavior, that is more cumbersome than being able to set a default and allowing an overriding value where necessary. If I'm trying to document or mock up an API with several hundred calls, this one feature could save me enormous amounts of time.

[jaydorsey]

For one, if adding a {{url}} variable is recommended, when I import a collection from a swagger spec, then I would hope that the Base URL variable would be added to each URL for me.

When I imported a swagger definition using postman latest, it did add {{baseUrl}} to every request for me. I think I had to set the host in my swagger definition (e.g. host: null didn't seem to append it)

[mikereiche]

V7.7.2 Not sure if this is the right thread for this - when I import my api-docs, it shows the variable baseUrl is //localhost:9090/ . When I select a service, it shows : GET {{baseUrl}}/books Substituting for {{baseUrl}}, this results in //localhost:9090//books - which doesn't work. The correct url is http://localhost:9090/books Is there some way to get postMan to use the correct baseUrl? swagger | "2.0" info | description | "Api Documentation" version | "1.0" title | "Api Documentation" termsOfService | "urn:tos" contact | {} license | name | "Apache 2.0" url | "http://www.apache.org/licenses/LICENSE-2.0" host | "localhost:9090" basePath | "/"

[bdelamatre]

This is such an obvious option to add that a dismissal to add it by Postman is hard to accept. All that is needed is a "base url" option that can be cascaded and set with variables, just like how Authorization works. That option would be as easy and logical as the Authorization configuration, saving users from having to specify {{VARIABLE_NAME}} on every single request that they create, resulting in a better user experience for your software.

[leobrines]

This is my solution:

1. Set environment variable "url"
2. Go to Collection -> Edit -> Pre-request Scripts
3. Add this pm.request.url = pm.environment.get('url') + pm.request.url
4. And start using /users in postman request instead of {{url}}/users

Based on the idea of default headers

[ObaidShahid]

@leobrines above mentioned solution kept on giving me undefined. See below, undefined/api/login Here is URL created in pre-request script pm.request.url = pm.globals.get("BASE_URL") + pm.request.url; Please help.

[leobrines]

@leobrines above mentioned solution kept on giving me undefined. See below, undefined/api/login Here is URL created in pre-request script pm.request.url = pm.globals.get("BASE_URL") + pm.request.url; Please help.

You are using "pm.globals" to get url. Make sure to set "BASE_URL" in the "Globals" section in postman.

If you have "BASE_URL" in environment variables, you must use pm.environment.get("BASE_URL")

[ObaidShahid]

e sure to set "BASE_URL" in the "Globals" section in postman.

If you have "BASE_URL" in environment variables, you must use pm.environment

Above solution was not working as i was accessing global variable in collection scope. Then defined variable in collection and able to access it in then using pm.request.url = pm.variables.get("BASE_URL") + pm.request.url;

[BoraKaraca]

@leobrines Thank you its worked me

Postman new version its very simple global variable to set this way.

I import json data in postman all request looks like {{baseUrl}}/api.. I use this steps Before Step1 Step2 After

[michahell]

When working with multiple (Swagger / openAPI generated) collections in postman, and each collection having a different {{baseUrl}}, this is a bit of PITA: For users to be able to easily switch between each microservice, I now have to create an environment for each of the services just to have a {{baseUrl}} variable that is correct for each microservice 😢

Why can this not just be an import option? Have the option of choosing what to do:

• create a {{baseUrl}}
• or use the actual openAPI v2.0 spec host field in the root

[arlemi]

@michahell Have you tried using Collection Variables to set the baseUrl? That way you can keep the same environment for all collections and have their base url set up at the collection level.

[michahell]

@arlemi Ah, this might work indeed! I would need to modify the collection programmatically, but I'm already doing that for authentication. can collection variables themselves contain references to environment variables?

So, could I create a variable like this:

key: baseUrl value http://microservice-name-{{environment}}.bla.io

this way, the collection knows what it's {{baseUrl}} should be even based on which environment you'd like to target (I.E. dev, staging, acceptance, prod, what have you)

[arlemi]

@michahell I'd never tried that but it turns out it works! 😄 See GIF below:

• Collection variable {{baseUrl}} set to https://postman-echo.com/get?userid={{id}}
• Environment variable {{id}} set to 55
• Sending a request to {{baseUrl}} resolves to https://postman-echo.com/get?userid=55

[michahell]

Brilliant @arlemi !

[GalTidhar-Deliverr]

@arlemi this simply works!! completely don't understand why it's not something automatic that the postman should offer while generating the collection, it has a place to define environments, just put it there and connect accordingly, anyhow the solution above is remarkable and works simple and efficient. just in case it's not completely clear to anyone reading in the future

1. Generate a collection from an openApi spec
2. Define the API URL in all environments as you would do without the help of openApi
3. Go to the collection -> Variables and reference the autoGenerate baseUrl to the global variable in the relevant environment

@arlemi THANK YOU!

[furkanarabaci]

@arlemi Do you know any convenient way to change the naming of the baseUrl?

I'd like to change the environment variable to something else like host_name instead of baseUrl. Since I can't bulk edit the collection/folder since postman removed that feature, (ref: #4898) I either have to manually edit everything.

[GalTidhar-Deliverr]

@furkanarabaci there use to be environment variable for a collection, where it can be set

[furkanarabaci]

@GalTidhar-Deliverr I know, that's now what I meant. The problem is, I don't want to use the name baseUrl for the variable, it is used for something else.

[GalTidhar-Deliverr]

We had the same problem, it should not be touched by any collection in order for this to partially function normally, this feature is not totally baked, you would expect this option as a part of the generation, and for the existing servers to be automaticly populated and authentication to be set to inherit

[furkanarabaci]

@GalTidhar-Deliverr I see, then I have to edit all of it manually, that's a shame. I've tried manually editing the json file before exporting, but that also didn't work.

[GwynethLlewelyn]

This thread is already half a decade old, but nevertheless still relevant... why was it closed? I find it amusing that one needs to programmatically construct the various components of an API call inside Postman... which should be doing exactly that kind of work for us! In other words: setting up a quick & dirty test suite inside Postman — which is an excellent tool for that! — due to the lack of propagating things like the base URL, version, etc. everything needs to be done... in JavaScript. So, in essence, you could simply write your own test suite from scratch — instead of relying on Postman — since the amount of time required for writing code in Postman is essentially the same as writing a test suite in {{insert your favourite programming environment here}}. I'm not saying that Postman should work like {{insert competitor's name here}}. I'm just saying that there are some assumptions that are common to all APIs inside a collection — authentication, sure, is the best example brought up here — and those are expected to be standard features, not something end-users must write code for implementing them. Also note that one of the major uses of Postman is to automatically export the documentation for a whole API in a consistent format, to be used in {{insert your favourite documentation generator here}}. If a crucial, specific aspect of such functionality is actually encoded in JavaScript, it means parsing the results using some regular expressions, to assemble a file in {{insert favourite API documentation file format here}}; it also means figuring out how someone did it on one particular Postman API (assuming they have provided their JavaScript with the rest of the API) in order to adapt to one's own environment (as @furkanarabaci explained so well — sometimes, 'common' variable names have been used for different purposes, and it's up to the Postman user to fix all those references when merging different APIs together). The result is... messy, to say the least. And, as mentioned by @furkanarabaci, it doesn't help that the global search & replace functionality was removed, too. In short: a mess 😞

---

Exercise to the reader: write your own GitHub action to replace the variables above. 😼

[abiiranathan]

It's incredible that someone thought this was not necessary. 🤬

[arlemi]

@abiiranathan You can set a base URL at the collection level: https://learning.postman.com/docs/sending-requests/variables/#defining-variables

If you're looking for something else that's missing please open a new feature request.

[GwynethLlewelyn]

(OT, but thanks to @postmanlabs for deleting the comment/spam or whatever that random noise was)