JSON string values are being converted into numbers by Retool body query

  • Goal:
    I need my json values to be sent as strings wrapped in double quotes, as the endpoint we're working with requires these fields as a string/wrapped in quotes.

  • Steps:
    See how even a raw hardcoded example is being converted into a number behind the scenes:
    "keyname":"1234567" turns into "keyname":1234567

  • Details:

Hi @alan, I tested this on Cloud by making a request to httpbin.org, which just echoes the request, and I did not experience this issue:

Are we on Cloud or Self-hosted Retool? If Self-hosted, which version?
On the other hand, which API are we making this request to? Perhaps this is happening on their end.

Hi @Paulo
We're on Retool cloud, and I'm making this request via an OpenAPI resource.

We're able to POST figures wrapped in quotes to this endpoint via curl and postman just fine, so we don't have a problem with the request on the endpoint side.

Wouldn't I be correct to say the 'Output' section in my screenshot showing:
"body": "{\"test\":12345}"
is proof that Retool is manipulating the body before it even sends to the endpoint? Perhaps this is limited to OpenAPI resources?

I'm not able to reproduce this for a simple OpenAPI endpoint that lets me define the body with parameter fields in retool, but when it's just a 'Request Body' field like in my screenshot above, it manipulates the values.

In this endpoint's case, the body is an array of objects with nested objects within it, so presumably that's why it defaults to 'Request Body' for this endpoint.

The endpoint/swagger has a request schema defined in which correctly states the field is only of type String.

Unfortunately, I can't realistically use a REST API type resources for this endpoint as a workaround, as we've got authentication setup for our OpenApi resource which would mess with our team's understanding if they had to learn about another auth flow here just for this endpoint.

Since the endpoint we're using is auth'd, I can't share it here for reproducing, and unfortunately can't find a similar test Swagger api with a more complex body request to help reproduce :thinking:

@Paulo actually, I've found a test swagger that lets me reproduce this without auth:
Set up an OpenAPI resource with the swagger: https://petstore.swagger.io/v2/swagger.json

Now use the createWithArray endpoint, with a body like:

[
  {
    "firstName": "12345"
  }
]

Notice how the quotes are being stripped from the value:

{
  "request": {
    "url": "https://petstore.swagger.io/v2/user/createWithArray",
    "credentials": "same-origin",
    "headers": {
      "Content-Type": "application/json",
      "accept": "application/json, application/xml"
    },
    "method": "POST",
    "body": "[{\"firstName\":12345}]"
  },

I believe I've fixed this now, by wrapping the json object.value in quotes in the retool request body field. I thought I'd tried that initially, but just got it to POST with that field as a string now.

"{{ membership_json.value }}"

1 Like

What's strange though, we have a similar endpoint with the same field and number values in another endpoint. But because of how we're passing in a full json, but splitting out the values into params and the rest into the body, it doesn't have this same issue with number conversion, and does not require the variable to be wrapped in a string in the request body.

I don't really understand why there's a difference, I'm guessing there's some conversion happening that I can't see, when I pass in the top level .value, but when accessing an object of .value like in this request, that conversion isn't happening for some reason :person_shrugging:

Thank you for diving deep into this issue and sharing your findings. I'll try reproducing with the test swagger you shared. From looking at the screenshot, it does look like it might be related to the k-v pair being nested under another object.

The workaround you shared is perfect and it'll help other users running into this issue. However, it would be ideal for this to work without the need for it.

1 Like

I was able to reproduce this issue, here is a screenshot from my network tab:

We created the internal bug report and will update you here when it's fixed. On the meantime, I marked your workaround as a solution in order to unblock other users that run into this issue and find this topic.

1 Like