Bug in webhook integration event name


I think I found a bug in the webhook integration event name.
When I have 2 webhooks, one with the event name ‘pushbullet’ and another one with the event name ‘pushbulletjurjen’, it sends a trigger to both this webhooks when using the code:

Particle.publish("pushbulletjurjen", "This is a message!", 60, PRIVATE);

I expected it will only use the webhook with the event name ‘pushbulletjurjen’, so I wonder why it is also send to the ‘pushbullet’ webhook. When I edit and rename the ‘pushbullet’ webhook event name to ‘pushbulletsomethingelse’ it isn’t used anymore. So it looks like the Particle,publish function is fired when the first part matches and is not using the unique name.


That’s the expected behavior. The event name in a webhook or subscription is a prefix, so it will match everything beginning with that string. That’s intentional, so you can use a single webhook or subscription to handle multiple events.

1 Like

Hi Rick,
Thanks for answering :slight_smile:

Is it common that a webhook event name is a prefix, or is this only at Particle? It did cost me a lot of time to debug receiving duplicate messages. I am not a good developer, but a senior developer looked with me and didn’t expected it and found this a bug.

Kind regards,

I don’t think it’s that important whether or not others do it the same way or not, but that the behaviour is clearly documented, and it is (at least when you know where to look :blush:)

However, a good take-away from your comment is that visibility of that fact is worth improving. Hence I just filed an issue report


Hi @ScruffR Maybe it is not important to you, but in my opinion it will enhance user experience if standards are being used. Anyhow, maybe there is a good reason doing it this way?

Thanks for helping suggesting to add a tooltip to make it more clear.

True, but which standard would you propose?

There are several

  • MQTT topics are hierarchical and use wildcards (*, #)
  • STOMP topics are hierarchical and use wildcards (*, **)
  • Azure IoT Hub uses prefix/suffix filters

I’m not too seasoned with all possible “proprietary standards” and flavours thereof, but IMO as long the IoT world hasn’t yet managed to settle with one definitive standard all concurrent “pseudo standards” need to show their pros and cons to (maybe) find the best.

BTW, not adhering to standards does not prevent success. For instance Apple is a big example for that. How many standards have they just thrown over board to create their own (e.g. TRRS connector - the LRMG pinout predated the now “standard” LRGM pinout)


Lol. That is one of the reasons I don’t use Apple. But true, even Google Home Mini device is using Micro USB instead of their new USB-C way of working.

Normally I would say ‘topics are hierarchical and use wildcards’.

1 Like

I got caught up in this prefix issue awhile back also. I figured it out eventually but not until this post has it become clearer to me.

So how many letters of the prefix does it take to get all other webhooks to respond to it?

Like is it 2, 3, 4, 5,. … letters that are required to match for all other webhooks with the same starting 2,3,4,5 … letters to also trigger that same webhook?

Is 2 letters enough? like if I name a webhook: Weather

Would any webhook start with “We” trigger the Weather webhook? or does it require “Wea” to trigger the Weather webhook?

All of the event name must match. So if a webhook or subscription had the event name “weather” then the event would have to be at least “weather”.

But since it’s a prefix, “weather1” or “weatherx” or “weatherAlert” would all match.


That makes sense and that is what I was having happen.

I was just adding on to the previous webhook name some and it was trigging both of them. This was before you had the ability to edit already made webhooks via the web interface.

This caught me off guard too. Post helps.

For me I was porting my webhooks on my development account to production webhooks so I had hooks like “login-dev” and “login-prod” :neutral_face:

1 Like

Glad this thread helped :+1:

However, now it can’t be blamed on the lack of visibility anymore :wink:

I guess visibility is fine. I bet most people would run into this since the typical pattern (I think) would be to go through basic tutorials, get a feel and then build on things yourself. Those basic tutorials won’t cover cases like these ones and is very unlikely one would scope the documents in detail (or hover over “i” icons if the tutorial guided them past it) before expanding. Or thats just me =)

But once you run into the problem, finding the root cause isn’t too hard. All in all about 30-40mins for me to realize that 2 APIs were being triggered and then find the post and docs. But then again, I started debugging from my firmware up and eventually hit the cloud stuff. Might have been shorter if I went the other way but since I was porting APIs over (i.e. literately copying), I thought that it was more likely I had done something wrong with device IDs, typed the API names wrong or did something wrong when creating my first product.

1 Like


I for one (and I suspect there is more than one) find naming approach this counter-intuitive.

Here is what I would expect:

  • Publish “This-is-a-webhook”
  • Both “This-is-a-webhook” and “This-is-a-webook-v2” would fire

Here is how it works:

  • Publish “This-is-a-webhook”
  • “This-is-a-webhook” fires and “This-is-a-webook-v2” does not.
  • Publish “This-is-a-webhook-v2”
  • Both “This-is-a-webhook” and “This-is-a-webook-v2” fire.

I know it is documented this way and there is also a helpful info bubble. But I still feel like the Publish being the “prefix” not the Webhook would be more intuitive. At least to me.

I have been meaning to post this for a while so there, I said it. Now, I will go back to using this feature as it is intended (and documented) by Particle. I feel better having got it off my chest.


Webhooks are using the same logic as Particle.subscribe().
Also the way how you named your webhooks inferred a certain (contradicting) logic.
But suppose a different type of naming the current behaviour might be the logical behaviour:

Mulitple events

  • environ_Temp
  • environ_Humidity
  • environ_WindSpeed

may want to trigger the same webhook

  • environ_

then the other way round would be counterintuitive, right?


Yes, you are right. I like your environ_ example.

Thanks, Chip

1 Like