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!
When this happens, ping me on twitter! I'll send some customers your way. One of my most frequently asked questions is if I know of an easy way to host webhook handler code. I usually point to Zapier, but I'd rather point to Hookdeck. :)
For python devs, this is a great framework to easily create and deploy them - https://github.com/aws/chalice.
These are AWS Lambda's hard limits, and are too low for many webhook applications.
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.
Our largest MRR contributor is the team plan right now, but in terms of total count of plans, it’s the individual by about a factor of 2. It would be very hard to build a business of the individual plans, so teams are our focus. To our surprise, there are very few free plan accounts if you exclude “dead” users (signed up but never used it).
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.
For Stripe specifically, the later is best because of the encoded timestamp in the hmac signature and that's what we do for our own Stripe webhooks.
Does that make sense?
Technical teams use Hookdeck to receive webhooks reliably. However, Hookdeck itself makes no assumption about what those webhooks are used for or do (we don't run workflows). You can think of it as the backbone/infrastructure to manage and run your asynchronous events without having to put together queues, workers, ingestion services, alerts and logs.
That being said, check out this blog post https://hookdeck.com/blog-posts/hookdecks-approach-to-reliab... about our approach to reliability. Essentially we’ve decided to focus on ingestion by reducing the dependencies to a minimum and completely isolating it from the rest of our infra. We can’t guarantee 100% uptime, that would be unreasonable, but we can have a better likelyhood at ingesting your webhooks than you do.
Aren't you on $Provider too?
Wouldn't you be just as reliable as anyone else in $Provider? (But adding complexity)
I guess I don't see the problem.
You can build reliable ingestion, and we aren't reinventing the wheel on that front. The difference is that we've taken the time, and many teams prefer to invest that time elsewhere.
We can also take some extra steps (and will), such as having multiple $Provider as fail-over.
[EDIT]
To add to this, Hookdeck ingestion reliability is only part of the value proposition. What customers really appreciate is the visibility and error recovery. They don't have to build a robust asynchronous processing system. They can just deploy an HTTP endpoint and call it a day.