Any way to use non-standard query parameter delimiters, such as semicolons?

We have a third party software solution that provides an API but it uses non-standard query parameter delimiters of a semicolon instead of the usual ampersand. For example, their API URLs look something like this:;key1=value1;key2=value2;key3=value3

We’d like to be able to document the individual parameters in Postman’s “Params” section using the usual parameter key/value/description columns for each parameter, as well as being able to easily manipulate these query parameters like postman allows for ampersand-delimited query parameters.

I sincerely hoped there would be an option within the request’s settings that would let us change the delimiter for this request from “&” to “;” and we’d be home in time for dinner, but alas, no such luck that I could find.

We don’t want to change it globally, because we do have other requests that use the standard URL-style “&” delimiter.

I’ve searched the forum as well as within Google and so far haven’t found an answer, so I’m afraid this is simply not supported.

Is there a way this can be done in Postman, and if so, how?



In this scenario, I would hardcode the url and document the variables manually.

Hopefully you’re using a separate collection for documentation than you are for testing (if you aren’t, you should be!).

In your documentation collection, I would make the url the full example like what you have provided, but in the description of the request, I would use a markdown table to list the query parameters and what they are.

you cannot do that in the url section but can modify the url to make it that way using pre-request.

first set url as :

and in pre-request use:

params = "?"+pm.request.url.getQueryString()
newparams = params.replace(/[&?]/g,";")
pm.request.url = pm.request.url.toString().replace(params,newparams)

That is essentially the approach we are taking. We have been coding the URL as-is and documenting the parameters manually using a MD table in the description in lieu of native support.

What is the reasoning behind your statement that people should duplicate their work and have parallel copies of their requests for documentation and testing?

Interesting approach. I like it since it allows us to use the native query parameter support in Postman, but I think we’ll probably stick with the keeping the URL as it really is and manually documenting the query params in the description using a markdown table so the generated documentation has the real URL listed.

Thanks to you and thanks to @allen.helton for your replies.

1 Like