i.e. &where=%7B%22key1%22:%22value1%22,%22key2%22:%22value2%22%7D
JSON.stringify + Retool generates:
%7B%22key1%22%3A%22value1%22%2C%22key2%22%3A%22value2%22%7D
It looks like Retool is still encoding parameters instead of letting the end user determine what to send.
Am I going to have to hack together a convoluted solution for this simple problem that I keep finding people asking about in the forum?
Hi @keif, welcome back! 
As @jamesg31 mentioned on this topic, this is to prevent unsafe characters from being on the url. That being said, we understand that there are times when we would like the freedom to turn this off. As you saw on the topic you linked, this an existing internal request that we are happy to collect more feedback and +1s on (I added your feedback to it).
On the meantime, did this workaround work for you?
Hey @Paulo , thank you!
The workaround, sadly, does not work.
I am working on adjusting the API, but due to its age and use, it requires a lot of attention to verify the change doesn't break anything (utilizing Python's EVE framework). My python is rusty, but whatever, it'll give me more excuse to dive in.
Thank you for adding a +1 for me - I understand the reasoning but I prefer to let the "end user" (i.e. me XD ) be accountable for the sanitization of data versus handing it off to someone in a "black box" of sorts.
I think it's also around how Retool is showing the "preview" data - so it "looks pretty" (i.e. "{"jsonkey":"jsondata","but":"no escaped quotes"}" but it's not actually the data being utilized that creates a disconnect between "what Retool shows me, versus the actual string being used in the application."
You are welcome! We'll update you here with any updates on the FR.