Noticing on the dashboard that the published responses to webhooks changed from hook-response/your_web_hook to hook-sent/your_web_hook…
Was this change on purpose or just a bug?
Hook-sent is an additional response to tell you that the webhook request was sent.
You should still be receiving “hook-response” 
Strange, we had never seen it before. Also, for about an hour this afternoon it was the only response we were getting.
Weird. Seems like the server did no respond though?
Well I believe the server responded with the correct content, however it was under the publish tag “hook-sent/…” which our devices are not subscribed to. So basically everything was failing for some time there.
We use webhooks to sync data with our servers on device boot. (It just so happened that we were doing device boot tests this afternoon… we probably wouldn’t have caught this otherwise.)
Given our experience with the reliability of the webhook pub/sub (75% on a good day - at least when we were running the tests a couple months ago) we continue to call the hook until we get the expected response. So we’ve coded for missed webhook calls but not for this. Is this a case we should be planning for? I didn’t see any documentation on “hook-sent”…
@kennethlimcp - further webhooks development...
I registered my webhook with the CLI as follows:
particle webhook GET schedule-zone-sync http://rest.neosmartblinds.com/sync
Then when my device boots it publishes the following to initiate a sync:
event: schedule-zone-sync/200028000447343232363230 data: {"data":"null","ttl":"60","published_at":"2015-10-16T18:41:30.533Z","coreid":"200028000447343232363230"}
Most of the time we just get back:
event: hook-sent/schedule-zone-sync/200028000447343232363230
data: {"data":"undefined","ttl":"60","published_at":"2015-10-16T18:41:30.541Z","coreid":"\u0000�U\u001b)"}
Note the strange characters in the coreid...
Then only when we're lucky we get back.
event: hook-response/schedule-zone-sync/200028000447343232363230/0
data: {"data":"{"count": 2, "error_msg": "null", "current_tz_offset": -4.0, "schedules": "062-12:22-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:45-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-16:17-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-10:59-036.000-15-dn,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-1","ttl":"60","published_at":"2015-10-16T18:41:30.844Z","coreid":"\u0000�U\u001bG"}
event: hook-response/schedule-zone-sync/200028000447343232363230/1
data: {"data":"2:00-036.000-15-up,062-12:00-036.000-15-up,062-12:00-036.000-15-up,062-13:30-036.000-15-up,062-13:36-036.000-15-dn,062-16:22-036.000-15-dn,062-12:21-036.000-15-dn", "next_tz_offset": -5.0, "error": false, "order": 1, "next_offset_at": "2015-11-01T06:00:00"}","ttl":"60","published_at":"2015-10-16T18:41:31.098Z","coreid":"\u0000�U\u001bG"}
Which is the desired response.
What's the deal with those characters, and is there anything I can be doing to improve reliability. Have you changed anything in the last few weeks? Our webhook test a few months ago were doing just fine...
@kennethlimcp - Any thoughts on those non-ascii characters? While the webhooks have improved in reliability, we’re still seeing what looks like corrupted bytes in the coreid field in hook-response/ and hook-sent/.