- Uncertain security: signing notifications is in the spec
- Development and testing: ideally, with libraries that implement the spec, you can assume that the websub part will 'just work' and only need to test your handler function.
- Misbehavior is onerous: subscribers need to actively confirm their subscription every once in a while. This might seem complex, but it allows for periodic checks if the server/client is still functioning as expected, and ideally can be handled automatically by libraries.
- Retries: the spec leaves some room here, but again, a library can handle this.
As I decided to use WebSub as an alternative for a 'plain' webhook for a project recently, I wrote a library for the Flask web framework: https://github.com/marten-de-vries/Flask-Websub. I personally hope libraries for other frameworks will follow now the spec is moving less.
I tried looking for websub on w3.org without using a search engine and it was a challenge (finally found it)
For several years now, we've had this sort of hook-via-code in the Rules engine on our Auth0 identity product. It's been such a powerful enabler for many different integration scenarios that we thought that other companies may find the technology useful for their platforms.
Since committing to building Auth0 Extend, we've seen Twilio launch their functions  and just today CloudFlare launched its Workers . It seems like the this is an approach that is in its infancy but that is here to stay!
Definitely a good way of doing things, still looking for more beta testers but feedback is very positive so far.
https://get.converse.ai/v2.0/docs/plugin-development if anyone wants to kick the tires on it, all feedback welcome.
As the article alludes to APIs change over time, and so you can find the data that is submitted to you changes. In my case I setup an end-point that responded to push events from various code-hosting services.
I found that the three "main" git-hosts sent widely different data in their webhooks, and updates we often painful. (Github, bitbucket, and .. something else. I forget now.) Trying to have one end-point to handle all services was a recipe for frustration and failures. Even parsing out the basic details was hard:
* This is the SSH repository URL of the thing that was committed to
In the end I moved to self-hosting git-repositories, rather than allowing users to point at my webhook. That allowed hooks in the master-repos to fire.
(In my case I trigger DNS updates when git commits are made.)
* If webhooks are configured by UI, then you have to contact the user and tell them their webhook is gone, e.g. via email.
* If webhooks are configured programmatically, then the endpoints ought to be able to be swept up silently, and the receiver should know to periodically refresh the configuration for as long as it cares about it.
Ideally all webhook implementations would work the second way, but unfortunately it is not standard practice.
The thing is, all the hook does is put a message on a queue…