Nice. These are very useful feature and I can see myself subscribing for these. May I suggest you highlight these as the main features and demote, remove or re-word "not having to invest significant engineering resources in making a reliable webhook calling system" bit (not exact words). Just a suggestion, don't claim to know more about your business than you but as a possible customer, this claim being at the top would throw me off TBH.
> I mentioned it elsewhere in this thread, I don't see how this can be a library. It's a standalone service that needs to be run and monitored, needs to scale with your usage, and you need to make sure it doesn't hang, the queue doesn't get too long, and etc. I actually say it in the post, webhooks aren't as simple as they seem.
They definitely aren't and I know that from building some quite non-trivial ones and I did build some of those as libraries used across projects in the same company. Also, wouldn't my scale be the same irrespective of whether I call Diahook or anything else directly? I still need to make same amount of calls, have same queue, same retries etc.
> I think the same can be said on every other API company, including Stripe, Sendgrid, Twilio and etc. If this is a concern for you, you need to take care of that, if it's not a concern for you, then Diahook is not any different.
This should definitely be a concern for everyone unless missing outgoing webhooks is fine for a service and I agree Diahook wouldn't be any different which was my original comment. Sorry if I came across as dismissive. I was just pointing out how using something like this cannot be a reason to eschew fault tolerance in outgoing webhook code.