Handling of encoding URL parameters

  • Goal:
    I have a URL parameter that needs to be sent in a specific format.

i.e. &where=%7B%22key1%22:%22value1%22,%22key2%22:%22value2%22%7D

  • Steps:

JSON.stringify + Retool generates:

%7B%22key1%22%3A%22value1%22%2C%22key2%22%3A%22value2%22%7D

  • Details:

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! :slightly_smiling_face:

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?

1 Like

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."

1 Like

You are welcome! We'll update you here with any updates on the FR.

Hey Do we have any update , i am facing the same issue where i am forming a url as :
"https://offer-builder.env047.test/v1/offer?created_at.seconds=(1725883743,1728475743)&page_number=0&page_size=50&product_ids=NQH8ITXSL8&sort_v2=valid_till.seconds:asc"

but it is automatically getting encoded to :

"https://offer-builder.env047.test/v1/offer?created_at.seconds=(1725883743%2C1728475743)&page_number=0&page_size=50&product_ids=NQH8ITXSL8&sort_v2=[valid_till.seconds%3Aasc]"

Do we have a solution so thats it doesn't encode what i am sending?

Besides the workaround linked above, a customer reported that using a transformer worked for them. Their case is a bit different because the subdomain the params come from other queries but here it is:

I added your +1 to the internal feature request.

How can i add this transformer while making RESTQuery?

Create a transformer like the following:

const productIds = {{ referenceToyourInputOrData }}
const pageSize = {{ referenceToyourInputOrData }}
const pageNumber = {{ referenceToyourInputOrData }}
const createdAtSeconds = {{ referenceToyourInputOrData }}
return decodeURI(`https://offer-builder.test/v1/offer?product_ids={{productIds}}&page_size={{pageSize}}&page_number={{pageNumber}}&created_at.seconds={{createdAtSeconds}}&sort_v2=sortBy.value`)

Note: On your last URL param, sort_v2=sortBy.value looks like it may be missing {{ }} ?

Then, on the REST API query just set {{ transformer.value }} for the URL.

This is still not working, even after creating a transformer or just inputting the URL as a variable.

This is for a 3rd party API, so i have no control over this endpoint and am effectively stuck.

As an example, https://example.com/endpoint?start=2024-10-14T19:02:36Z has the colon encoded no matter what I do.

Hi @yuppers43, welcome to the forum! :wave:
I'm sorry this is blocking you from building your use case. I was able to reproduce what you are reporting and I surfaced it internally.