How to choose your own server variables?

[JaredAAT]

consider an OpenAPI v3.0.3 server specification like:

servers:
  - url: "{url}/content"
    description: The production API server
    variables:
      url:
        default: https://api.example.com
        description: the server url

this will make the OpenAPI to postman convertor to create a top level variable in the postman collection like:

"variable": [
    {
        "description": {
            "content": "the server url",
            "type": "text/plain"
        },
        "type": "any",
        "value": "https://api.example.com",
        "key": "url"
    },
    {
        "type": "string",
        "value": "{{url}}/content",
        "key": "baseUrl"
    }
],

and a url on a request like:

"url": {
    "path": [
        "create"
    ],
    "host": [
        "{{baseUrl}}"
    ],
    "variable": [
        {
            "description": "the server url",
            "type": "any",
            "value": "{{url}}",
            "key": "url"
        }
    ]
},

which then shows up in Postman Like: "{{baseUrl}}/create/"

Is there a way to force the generated collection to not amalgamate the variables... really we'd like the URL in postman to look like: {{url}}/content/create/

[VShingala]

@JaredAAT ATM, We don't have any way to achieve this. For now, we can treat it as a feature request but I'd like to understand your use-case and why the need of showing {{url}}/content/create/ instead of {{baseURL}}/.

[JaredAAT]

Hey @VShingala. So we already have a postman environment setup where we have an environment variable as {{url}} that relates to https://api.example.com. So when we generate postman collections and import them, it'd be good to have them match our current postman environment. Also I feel that obscuring the path content (API endpoint) within {{baseURL}} kinda makes the file less useful.

[VShingala]

@JaredAAT Hmm, So our understanding at the moment is that as the entire {url}/content is mentioned as baseUrl, and as such we use it as is from definition in the generated collection. Basically, as baseUrl is common across all endpoints it's used as such. If someone wishes to have /content mentioned then one can just define https://api.example.com as baseUrl and keep /content as prefix to all paths e.g. /content/some-path under paths.

But yes, this differs from users to users according to their use case.