Can't use variable / dynamic value as Number in JSON request body

[ndizazzo]

I'm trying to define a request that updates fields for objects that have a number ID, and those IDs are returned to me in a prior API response.

I can't use those IDs as response body dynamic values, in the body of another request when I set the variable's type as "Number", but can when I set it as "String".

I understand that there's no indicator to what type the value could be, but can't it be assumed it will be the type specified in the current request body, and fail if the prior response value fails to parse as a number?

Thoughts?

What happens currently

### What I want ### How it could work

[mittsh]

@ndizazzo sorry for the massive delay... unfortunately we don't support number inside of the formatted JSON, and that's because of the way it's handled behind the scenes. Though, it's something we have in our todo list, and that should be added at some point in the future (we have other big updates planned, so I cannot give you a date on this).

As a workaround, you may want to switch to the Text format, and manually set a Content-Type: application/json header. The presence of the header will enable syntax highlighting in the text area, which will make it nicer. You can still format most of your JSON in the "JSON" view, and the convert to "Text" and your JSON will stay. Then just add manually your numbers inline...

A quick screencast to illustrate the workaround: http://cl.ly/15023Y3A3D3X

Will keep this open until we have a proper fix!

[andrewault]

Another vote for this one! I keep trying to do this. Doh! Thanks, Andy

[Obbut]

Any news on this?

[valeriomazzeo]

+1

[gabriel-jones]

It's been quite a while since you said you've been working on this, are you still planning to fix this?

[mcornut]

Up pls.

[antom]

+1 on fixing this (or even allowing environment values to have a type optionally set)

[natebrunette]

Even just being able to turn off lines of json text would be huge

[bkmu]

@mittsh et al. Now that we've clicked over to 2019 any updates with respect to a timeline for getting this nagging issue folded into an update?

[josefeg]

I don't like to pollute Github issues with thumbs ups and update requests, however this is clearly a bug with has been opened since 2015 and received no attention!

The workaround posted doesn't really work because as soon as you try to switch back to JSON view, you get the:

As the current request body is not a valid JSON string, converting to JSON will overwrite the current request body

error message. Paw is something that we pay for. As of December 2019, it's not able to import OpenAPI 3.0 definitions, it's not able to do GraphQL queries, and it doesn't allow us to have variables with numbers. These are things that all other competitors (Postman and Insomnia to name 2), which can also be used for free (albeit with some limited features), allow us to do.

[Vercoutere]

Another upvote here. This has been bugging me a lot!

[ushu]

By far one of the most limiting feature imo... I love the rest of the app please please fix this issue 🙏🙏🙏

[henning-meinhardt]

workaround isn't an option, really disappointed

[swehba]

This is a huge deficiency. Has it been fixed yet? This thread is now 7 years old!

[dev4dev]

I just ran into this issue and was disappointed by this thread =(

[Tazintosh]

Oh boy, We are end of September 2023, version 4.2, and I'm having the same issue! In my case, my environment variable is itself a json object and it get escaped: "auth": "{\\"realm\\":\\"shellyplus2pm… I found myself the "text" workaround before finding this topic, but it's a real bummer. What's the point of having a nice UI if it's to fallback to "coding" ways…

[we5]

+1