Webhook adding double quotes to boolean value

Troubleshooting
1

It appears that the Webhook is adding double quotes to boolean values, which is breaking the server side parsing of the JSON request. Is there any way to force this to stay as a boolean literal instead of being converted to a string? See example below:

Webhook JSON:

{
    "eventName": "lr_off",
    "url": "https://winkapi.quirky.com/groups/GROUP_ID/activate",
    "requestType": "POST",
    "headers": {
    	"Content-Type": "application/json",
    	"Authorization": "Bearer BEARER_ID",
    	"Accept": "*/*"
    },
    "json": {
        "desired_state": { "powered": false }
    },
    "mydevices": true,
    "noDefaults": true
}

Transmitted JSON:

{
  "desired_state": {
    "powered": "**false**"
  }
}
2

Hi @egaertner,

Good question! Is that the exact webhook json, or are you using a template value for “powered”?

edit: I ask because if that’s the exact JSON, then the value should be left alone. If instead you’re using a replacement template, like "{{VALUE}}", that system isn’t smart enough yet to preserve types, and since the template is passed as a string, it stays a string. I have a task in my backlog to provide a way around this, but I haven’t found a way to define that type information yet that isn’t a little awkward, but working is better than perfect! :slight_smile:

Thanks!
David

3

Hi @Dave ,

That is the exact webhook json, not using a template value. It’s still converting it to a string.

I would like to move to a template eventually, so good to know that’s on the list to preserve types, but in the short term just getting the exact json to be left alone would be very helpful to enable my application.

Thanks,
Eric

4

Hi @egaertner,

Interesting! I tested this on my end and also saw the boolean value wrapped in quotes… that’s weird. I’ll look into it and post back when I know more.

Thanks,
David

5

Hi @egaertner,

Neat bug! Turns out the CLI was causing that native type to be converted to a string, so the hook didn’t know any better. I just submitted a PR to the CLI that should fix this issue, it’s here:

When that gets pulled in, it should fix the issue you’re seeing. :slight_smile:

Thanks,
David

1 Like
6

Thanks Dave. Fix verified!

1 Like