Hey, Alex here. I'm excited to share Hookdeck along with my co-founders Eric and Maurice. It's a product we started working on after dealing with my fair share of webhook-related issues (missed webhooks, time-consuming troubleshooting) at our previous employers.<p>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.<p>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.<p>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!
This is pretty neat. If you could take it a step further and have integrations to send the response payloads to other services like S3, SES, SQL insert into Redshift, etc then it would be great.
This is something I am looking into at current as we are moving our subscriptions into chargebee and they send a lot of webhooks so this would be ideal for us.<p>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?<p>Thinking team plan would fit but not sure. Anyway is a cool product and solves us having to build the same thing in house.
This is pretty tangential, and doesn't matter at all, but many services do it and I'm always curious - is the second-most expensive ('Team') tier <i>really</i> your 'most popular'? Or is it just chosen to maximise up-selling return? Intuitively I would guess most users don't pay, next most pay the lowest individual, etc. - a few whales, lots of minnows.
I've been using webhook.site for my webhooks. The no-nonsense simplicity just gets me.<p>Meaning to try out this OSS alternative for a while: <a href="https://github.com/huginn/huginn" rel="nofollow">https://github.com/huginn/huginn</a><p>Thought of posting it here—maybe someone finds it useful.
From time to time I write a quick & dirty hooker.py. A flask based server just for this purpose. I'm sure I'm not alone to name like that.