Webhook POST with deviceId parameter

Cloud
1

Hey, I’m not sure if this is expected or if it’s a bug but if I have a webhook that looks like this:

{
    "event": "test-hook",
    "url": "https://foobar.com/api/foo",
    "requestType": "POST",
    "json": {
    	"deviceId": "{{d}}",
            "token": "{{t}}"
    },
    "mydevices": true
}

It will set deviceId parameter to the actual particle ID instead of using the {{d}} parameter. I was scratching my head for a while trying to figure this one out.

3

@Dave, this sounds like you need to look at this :wink:

1 Like
4

Hmm that seems weird, testing…

1 Like
5

Nope, I think I had an old webhook that was overriding my new one.

@peekay123 are you on here all day haha?

2 Likes
6

:stuck_out_tongue:

2 Likes
7

Haha, thanks all, glad you got it figured out! :slight_smile:

1 Like
8

Well… I’m still running into issues.

Here is the updated webhook

{
    "event": "tappt_request-pour",
    "url": "https://tappt.io/api/authorizations/pour",
    "requestType": "POST",
    "json": {
    	"deviceId": "{{id}}",
    	"token": "{{tkn}}"
    },
    "mydevices": true
}

Here is the message body I’m getting on the server:

{
	"event":"tappt_request-pour",
	"data":"{\"id\":\"2\",\"tkn\":\"\u0002ena3f6N1HkJR0StIe1NI0rWvEyxsdteROCk9LiaLAN9g01\"}",
	"published_at":"2015-10-21T17:32:00.833Z",
	"coreid":"2c0022001647343337363432",
	"deviceId":"",
	"token":""
}

Looks like it’s not setting token because tkn is too long. I replaced that value with “foo” and it worked. What’s the length limit on the parameters?

9

Looks like that character is the culprit... Wow that was annoying

1 Like
10

Hi @jlkalberer,

Glad you got it working! I’m curious if there was anything we could have provided that would have made tracking that down easier / less frustrating?

Thanks!
David

11

Well, I think that when I use particle webhook create something.json it should output some warning/error text if there is already a webhook with the same name.

adding particle webhook update something.json would be a nice to have.

12

Hi @jlkalberer,

Interesting, thanks for the idea! Sure, the CLI could warn you with a “Hey, this is allowed, but did you mean to add another one of these?” sort of warning? I threw an issue on the CLI for this here:

Thanks!
David

13

I concur. I was going nuts until I realized that creating a new version of a webhook merely added a new hook with the same name and they both/all get run, as I understand it. Once I learned this, I then deleted the current webhook and then did the create. I think having multiple webhooks with the same name could be advantageous in certain situations, so I would like to see that capability continue. As @jkalberer suggests, perhaps a warning would help the user be aware of the existence of older webhook(s) with the same name.

1 Like