> but I don't see the majority of webhooks used like this.
Can you give some examples of webhooks that are used solely for this "integration and extensibility" reason, because essentially all of my uses of webhooks have been to handle event notifications, but perhaps I'm just misunderstanding how you're making this distinction. For example, I work in fintech, and the main thing I use webhooks for is to get notified of a whole host of things that happen "in the real world" outside of my app (e.g. when a bank card is swiped, when an ACH is processed, when an account application is approved or denied, etc.)
> And even if they are, there's inevitably a bunch of cross-talk over the Internet to handle the event, make a follow-on request to the SaaS API, handle its response, rinse and repeat
I don't even understand why that would be considered a problem. So what, I make an API call to get some additional data so I can do something with it in my infrastructure? I mean, I'm going to need to write something to get the code to do what I want. There is literally 0 downside, from a business perspective, to "a bunch of cross-talk over the Internet" - why should I even worry about this?
I just generally feel that perhaps this article and what you are referring to have something very specific in mind when you talk about webhooks and what they're used for. I'd just argue that there is a much broader set of use cases out there for webhooks, so I think a better approach is to lay down how you think this kind of "plugin architecture" would be an improvement and highlight some examples where you think webhooks would be a bad fit.