Incoming webhooks are challenging because they require a well-built (and often complex) asynchronous system, and they are never a priority until they break. We were left with two options when I was building webhooks integrations: implement my own infrastructure to handle webhooks (ingestion, queuing, processing, monitoring, and alerting) or ignore the problem altogether and suffer from intermittent, often undiagnosable, failures.

We've found that's it's entirely possible to offer a platform-agnostic webhook infrastructure to consume webhooks reliably. Specifically, Hookdeck acts as a push queue to your HTTP endpoints. Webhooks are ingested by highly available services and go through an event lifecycle that manages webhook delivery. That allows Hookdeck to maintain a log of all events and delivery attempts, perform custom retry logic, routes webhooks to multiple destinations and even apply filters to received events. Hookdeck focuses on ingestion reliability, visibility and error recovery.

It's a satisfying space to work in, as webhooks are now commonly relied upon by most web-based technical teams, and the tooling around them has been lackluster - we have the ambition to change that. I'll be around to answer any questions!

Alex do you have any way to get a good estimation on total number of webhooks we would need to help with working out the best plan?

Thinking team plan would fit but not sure. Anyway is a cool product and solves us having to build the same thing in house.

Meaning to try out this OSS alternative for a while: https://github.com/huginn/huginn

Thought of posting it here—maybe someone finds it useful.