[Fixed] Webhooks callbacks are not reliable!

Hey @mayhew1955, thanks for your question. Sorry you are having difficulties. Posting the exact firmware that you’re using for the webhook will likely help debug the issue. Also, did you make sure the webhook appears when you run particle webhook list? Also, do you have the new Particle CLI installed? @Dave is the webhooks expert and may have some thoughts as well.

As far as your other question in terms of another simple way to call a web service without webhooks, an architecture that I’ve often used is having my device publish an event to the cloud using Spark.publish(), then creating a mini Node application that subscribes to that event using Particle JS. Then, you can make the API call in your JS, parse the response, and send that data back to your device by calling a function or publishing a new event.

Does that make sense?

1 Like

Hi @jeiden Thanks for the quick reply, the new particle CLI is installed and particle webhook list returns the following (it’s a temperature log):
Found 1 hooks registered

1.) Hook #555a23f22ccd38832b250421 is watching for "get_salon_temp"
    and posting to: http://api.thingspeak.com/channels/20769/feeds/last?key=5QS7Q31I9CR1DFU8
    created at 2015-05-18T17:40:02.333Z

Exact FW follows:

void setup() {
    //  particle serial monitor

    // Lets listen for the hook response
    Spark.subscribe("hook-response/get_salon_temp", gotSalonTemp, MY_DEVICES);

    // Lets give ourselves 10 seconds before we actually start the program.
    // That will just give us a chance to open the serial monitor before the program sends the request
    for(int i=0;i<10;i++) {
        Serial.println("waiting " + String(10-i) + " seconds before we publish");


void loop() {

    Serial.println("Requesting salon temp!");

    // publish the event that will trigger our webhook

    // and wait at least 60 seconds before doing it again


void gotSalonTemp(const char *name, const char *data) {
    // Important note!  -- Right now the response comes in 512 byte chunks.  
    //  This code assumes we're getting the response in large chunks, and this
    //  assumption breaks down if a line happens to be split across response chunks.

    String str = String(data);
    String TemperatureStr = tryExtractString(str, "field1", " C");

// Returns any text found between a start and end string inside 'str'
// example: startfooend  -> returns foo
String tryExtractString(String str, const char* start, const char* end) {
    if (str == NULL) {
        return NULL;

    int idx = str.indexOf(start);
    if (idx < 0) {
        return NULL;

    int endIdx = str.indexOf(end);
    if (endIdx < 0) {
        return NULL;

    idx = idx + 5;
    return str.substring(idx + strlen(start), endIdx);

The FW worked yesterday, then didn’t today. I reset my Core, changed it’s name and flashed the firmware again and it looks like it’s more reliable for the moment. It works now so fingers crossed !

I’ve edited your post to properly format the code. Please check out this post, so you know how to do this yourself in the future. Thanks in advance! ~Jordy


X-ref: HTTPS POST to Google Sheets for Low (no) Power Spark applications
FYI, I entered the example verbatim, but am not seeing results.

It’s frustrating, after minimal code changes webhook callbacks no longer work.
I can see the hook-response in the Dashboard but my function doesn’t trigger reliably.

This doesn’t make sense !

Hmm… mine started working; I ended up deleting ALL webhooks and recreating the one I needed. looking good now. You might give that a try.

Hi @mayhew1955,

There is an bug in the core firmware, where it will stop listening for a particular event subscription. I believe this bug is fixed in the new photon firmware, and will be available to the core soon as we continue to upgrade our dev tools to target alternate firmware versions. There have been a few workarounds posted about the subscription issue on the forums, here’s one: Losing Spark.subscribe() connection/subscription


Hi @Dave,

Thank you for confirming that it is a known issue, it’s much appreciated, I’ve been trying workarounds but nothing is as satisfactory as the promised functionality.

What’s your approximate ETA on upgrading the dev tools? FYI I’m using the online compiler.

EDIT: Upon further testing, I have run into a different issue or limitation. I have:

void setup() {
    // listen for the hook responses to commands sent to gas boiler
    Spark.subscribe("hook-response/turn_on_heat", ioBridgeHeatOn, MY_DEVICES);
    Spark.subscribe("hook-response/turn_off_heat", ioBridgeHeatOff, MY_DEVICES);
    Spark.subscribe("hook-response/turn_on_pump", ioBridgePumpOn, MY_DEVICES);
    Spark.subscribe("hook-response/turn_off_pump", ioBridgePumpOff, MY_DEVICES);

Therefore my Core is subscribed to 4 events. I can always publish all four webhooks but only one replies back -> the first one in the list, whichever one that may be. My first issue was when even that one stopped replying back.

I was expecting to be limited to 4 events, I’m only getting one with my webhooks. I tried a workaround by subscribing once to hook-response/turn_ and that worked once but further testing revealed that to be very unreliable, responses arrive seemingly at random.

I’ve currently adapted my code to work without webhooks but that means doing without any feedback, I’m firing commands regardless of whether they are heard or not! Looking forward to that next version of firmware, let’s see if these issues are solved.

For completeness, the functions are as follows:

void ioBridgeHeatOn(const char *name, const char *data) {
    Serial.println("Heat On Response");

void ioBridgeHeatOff(const char *name, const char *data) {
    Serial.println("Heat Off Response");

void ioBridgePumpOn(const char *name, const char *data) {
    Serial.println("Pump On Response");

void ioBridgePumpOff(const char *name, const char *data) {
    Serial.println("Pump Off Response");
1 Like

Hey @mayhew1955, looks like someone had an issue with multiple Spark.subscribe()s and @Dave came back with a solution here.

But regarding webhooks, I’ve also had a similar issue with the data being pulled into my project, so I’m on the edge of my seat for the new firmware update!

1 Like

@Dave, I just wanted to point out that outside of the subscribe issue, when I look at the dashboard I find that my webhooks are not even firing it seems as I get no response payload showing up (independent of subscribe). Often, I have to fire the webhook several times before getting the expected response.

Hi @peekay123,

Hmm. If the response body of the web request doesn’t have anything, then the webhook won’t publish a message back to your device, but I’ll look into it!


I’m going to tentatively second this @peekay123 and @Dave
PK had helped me design a mustached parser here Cloud JSON Parsing
The problem is that it typically fails 1 out of 2 times when I start up my Core. Often, once I get a response, it will work with subsequent GET requests that I make shortly thereafter. Once (while I was giving a demo too), it wouldn’t work for 3 or 4 requests. Don’t really know why. It is a big payload and I thought it may have been getting dropped or refused or not prioritized at the server level. One time it worked but took a very long time 60 seconds) to get a response. The norm for me is either 10 seconds or nothing at all.


Hi @ruben,

That’s really interesting, you’re typically not receiving the 1st event or so on your subscriptions, is that right?


@Dave, I see this on my events as well. First event does not return a reply and often 2 or more events go unanswered before getting a response.

1 Like

That is really interesting. OK, if that’s the case, then I think I know what’s up. Might take me a little while to fix.



good to hear

1 Like

What do you think the issue is?

Just to chime in here, I too am struggling (recent phenomenon but I can’t tell you when it started) with:

subscribe( )

Like the others I can see the responses on the Dashboard and get affirmation on the CLI:

JimBrowcBookPro:~ browerjames$ particle publish gmail_count
posted event!
JimBrowcBookPro:~ browerjames$ 

I’m compiling on updated particle dev and it works for less than 3 minutes after I reflash, and then no more.

FYI I am only publishing once a minute only from my Spark Core.

OK, so I definately see a pattern and you can see it here:

The first "device came on line"on the far left is a hard reset… after a few minutes, I see the cyan breathing flicker for a short duration, and then the “device came online” appears again.

After that (and this is all in just three minutes) subscribe( ) stops functioning properly.

The funny thing is, a month or two back, my subscribe( )s were working perfectly well over the course of a couple weeks straight. Now, like you guys, it only works for the first couple minutes maximum.

Hey all!

So, there is an old bug in the core firmware where the subscribe request isn’t sent after the session is dropped and reconnected. If your connection is dropping frequently, this can cause your subscribes to disconnect. I believe this is fixed in the newer photon firmware which will be available for cores soon as well. I suspect that is what’s causing the frequent subscribe failures you’re seeing above.