Comment by zbentley
6 hours ago
> receivers as well prefer the simplicity of webhooks.
Do you see receive-side customers as prepared to outright reject paying for vendors that only offer non-webhook event streams if there's a webhook-ful competitor available? Or is that preference more of the "well, it's easier to add a webhook route to our existing webapp than it is to run a stream consumer/cron/whatever, but neither of those two is cost- or effort-preventative" situation, where customers don't consider event delivery systems to be the main differentiating factor?
I know (from our customers) that some of their customers make buying decisions based on the availability of webhooks. I'm unaware of anyone doing it based on the availability of our other functionality (but it could be I just don't have the data).
Though the data I do have: how many people adopt these advanced endpoints in practice (as we offer these), and it's less than webhooks.
Interesting. There’s probably a market for the consumer side of that, then: really easy-to-integrate-with-common-app-frameworks-and-hosting-platforms runtimes that provide a polling/socketful event consumer and sidestep all the concerns that come with scaling webhooks on the consumer side. Your company looks like it helps with those concerns a lot! But if HTTP webhooks are the lingua franca, there’s only so much I can do as a consumer of them per TFA, you know?