Skip encoding for a URL parameter in RESTQuery

Using a RESTQuery resource automatically encodes URL parameters. Certain APIs do not work if the URL parameter is encoded. I am looking for a way of preventing a RESTQuery from automatically encoding a URL parameter.

In my example, I have a select tool, which on change sets a localStorage key. That key is used as the value for a RESTQuery, but when the query is submitted, the value gets automatically encoded. I have tried manually using decodeURI() and decodeURIComponent, but the query still submits with the escaped parameter.

Note: I have also tried using a temporary state instead of localStorage, but the result is the same.

An illustration of this is attached:

Hey Matthew, as you have noticed we currently encode all url params. There is no way around this behavior at this time. We do have an internal ticket tracking a requests to add a toggle to turn this off for specific queries. I've added your request to that ticket and can update you here as I get any more information on its status. Thanks!

Hi! I found this post when looking for a related problem. In my case there is the parameter key containing some characters that should be encoded, but they are not :frowning:

My example, I need to add


to my query, but the square brackets must be encoded, as the server does not accept it like that. Unfortunately, even if a add that encoded to my query as the parameter key, in the send API request the square brackets are decoded again.

Is that also by intend? Or maybe more a bug :wink:

Thanks and regards,

Hi all again!

I found a solution to my problem in the meantime by myself, so if anyone else is having the same issue it can be solved by wrapping the parameter value in double curly brackets and putting it as a string inside:

Hope someone my find that useful.


Hi, Is there an update to this? I have a similar situation where I'm passing a datetime filter to an API and the API does not accept it if when encoded

for me since the URL was fairly simple, and just the ? was being encoded, the following workaround worked for me:


Hey @abdulwasae thanks for sharing your workaround!

@suroor unfortunately there is no update on this at this time. We've bumped the internal ticket, and will post an update here when we have one.