alexbouchard

Some do; Gitlab, Otka, and Pipedrive come to mind. I think this is more about the expectations set over the last decade. If you do things differently, there's a need to justify it, and it's just perceived as less secure, regardless of whether it's true or not (the pros and cons are well articulated in the article).

I expect to have to answer that question a lot! Hookdeck is an event gateway, an unopinionated event log/message bus that operates over HTTP. It can be used to send webhooks, but 80%+ of use cases are for inbound webhooks (consumer side).

We think outbound is best served with an opinionated, purpose-built product, as the use case is very specific. The common feedback we got from event producers is that they are all annoyed by the complexity and costs of their current solution for sending webhooks. We think OSS / self-hosted is the solution to that. We drew from our experience handling 100 billion events, but also kept the scope to the table stakes to be highly efficient and simple to operate.

Event destinations' support is also crucial here because it means more efficient delivery with fewer errors, which can drastically reduce the overhead of event delivery.

From most watch market positioning I'd assume this to be true. However for me it's the exact opposite, the watch is a tool to cut phone use. All I care about is LTE and the minimum I need to get around the world. SMS, calls, WhatsApp, Gmaps. All existing decent looking watch have atrocious battery life to offer all the health features.

Been looking for something like this! Doc search just hasn't kept up with what's possible now and is such a hassle to get the indexing to work properly. Will try it out!

The push queue model has major benefits has you mentioned. We've built Hookdeck (hookdeck.com) on that premise. I hope we see more projects adopt it.

Yes and then format it back to JSON

YAML is just as effective at communicating data structure to the model while using ~50% less tokens. I now convert all my JSON to YAML before feeding it to GPT API's

Hookdeck (https://hookdeck.com) | Product Eng, Growth Eng, Backend Eng | Full-Time | Remote (World)

Hookdeck is an infrastructure to consume webhooks simply & reliably. Incoming webhooks are challenging because they require a well-built (and often complex) asynchronous system. We help developers spend less building and troubleshooting issues with their webhooks to focus on their products instead. We offer a complete infrastructure to develop, test, receive, distribute and monitor webhooks and asynchronous events.

If you are looking to be part of a early stage team, fully leverage your knowledge & talent, have an impact on the product experience and implement features from scratch then this might be for you!

We are offering competitive compensation, generous stock options and liberty over your geo & schedule.

We are looking forward to hearing from you! Email me at alex@hookdeck.com

Hookdeck (https://hookdeck.com) | Backend Eng, SRE, Product (Fullstack) Eng, Product Designer | Full-Time | Remote (World)

Hookdeck is an infrastructure to consume webhooks reliably. Incoming webhooks are challenging because they require a well-built (and often complex) asynchronous system. We help developers spend less building and troubleshooting issues with their webhooks to focus on their products instead. We offer a complete infrastructure to develop, test, receive, distribute and monitor webhooks and asynchronous events.

If you are looking to be part of an early (funded) team, fully leverage your knowledge & talent, have an impact, and work on hard scaling and concurrency challenges, this might be for you.

We are offering competitive compensation, generous stock options and liberty over your geo & schedule.

We are looking forward to hearing from you! Email me at alex@hookdeck.com

PH takes much more work and strategy but "success" is somewhat deterministic if you did your homework. In our case we saw similar uptake, signups and conversion then ~20h on HN front page over the course of a week. PH had a much higher half-life and we saw stable uptake for a few days while HN was all in the first few hours.

It was definitely worth it for us. Some of our best customers found us on PH and our lead investor first heard of us during our launch and reached out.

For the curious product is https://hookdeck.com

As a PH user thought, I'm not sure how much value you should put in the ranking..

That's right. In the context of pushed events, you have very little margin for error. It's definitely "solvable," but a bit part of the problem is that for most tech teams, it's not their bread and butter. Handling webhooks reliably is just overhead and work they aren't putting into their actual product. So you end up with a lot of not-so-reliable implementations.

I'm all for /events and appreciate the platforms with good support. However, we live in a world where people build event-driven and serverless architecture. The use cases go beyond replication, and webhooks are here to stay.

The thing is, you can get the best of both worlds by using webhooks in conjunction with /events reconciliation. That might seem like a lot of work, but that's what tooling is for. Webhooks are complicated to handle reliably, but it's a problem that has good tools the same way sequin (and many others) is helping developers solve the replication problem.

For webhooks, hookdeck.com (disclaimer, I'm the founder) address entirely the problems stated and will soon offer automatic reconciliation (currently running our polling Beta on with Shopify API)

Hookdeck (https://hookdeck.com) | Backend Eng, SRE, Product Eng, Dev Rel | Full-Time | Remote (World)

Hookdeck is an infrastructure to consume webhooks simply & reliably. Incoming webhooks are challenging because they require a well-built (and often complex) asynchronous system. We help developers spend less building and troubleshooting issues with their webhooks to focus on their products instead. We offer a complete infrastructure to develop, test, receive, distribute and monitor webhooks and asynchronous events.

If you are looking to be part of an early (funded) team, fully leverage your knowledge & talent, have an impact, and work on hard scaling and concurrency challenges, this might be for you.

We are offering competitive compensation, generous stock options and liberty over your geo & schedule.

We are looking forward to hearing from you! Email me at alex@hookdeck.com

Exactly, 6% of GPD is shockingly low cost to pay for net 0 annual growth in CO2. Now that doesn't mean you can practically deploy that capital but it makes me more bullish on carbon removal.

Hookdeck | https://hookdeck.com | Remote (Canada) | SRE & Backend Eng

Hookdeck is looking for a backend and reliability engineer to improve Hookdeck core platform and infrastructure. We are a small team of 3 operating completely remotely and without schedule.

We help developers spend less building and troubleshooting issues with their webhooks to focus on their products instead. We offer a complete infrastructure to develop, test, receive, distribute and monitor webhooks and asynchronous events.

If you are looking to be part of a early founding team, fully leverage your knowledge & talent, have impact and work on hard scaling and concurrency challenges then this might be for you.

We are offering competitive compensation & generous stock options.

Looking forward to hearing from you! Email me at alex@hookdeck.com :)

We've been getting that request frequently. So much so that it has jump to the top of our roadmap. How of curiosity, what would you use it for?

We emailed back and forth but haven't had the chance to talk yet. Looking forward to it!

Sweet! For payment and billing related webhooks, the total count of events tends to be relatively low. I can't help with an estimate per se without more context, but the team plans allow for 5 million webhooks, and the overage is 5$ per million. Does that sound reasonable? In any case, reach out to me, and I'd be happy to go into the details :) (contact in profile)

Hey! Yes we do, you can either verify the webhooks yourself as you normally would (we do not alter the payload, usual verification will work) or have Hookdeck verify the signature and resign it with a Hookdeck signature associated with your workspace.

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?

It boils down to the number of dependencies you have and the uptime of those dependencies. For instance, you'll need to write to some form of temporary or permanent storage like SQS, S3 or PG. What happens when this is down, or you've busted your connection limit? With webhooks, you have no control over the throughput, and enormous bursts of traffic are frequent.

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.

We don’t have a public SLA right now but work with customers directly to establish one that makes sense for both.

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.

I'm not familiar with Rundeck, but a quick google search makes me think it's a very different tool.

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's exactly it

Fair point! Honestly, I would have assumed the same.

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).

That's a good idea, we've been focused on getting up to speed to run your own code (which could just be a lamda uploading to S3, etc.) but directly integrating with some services is definitely possible. We just want to be careful not to become another Zapier, we want to help the tech teams!

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.

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!

Can you reach out to me, I'd love to talk about your use case and prioritize accordingly. Email is alex at hookdeck dot com

Transformations is something we haven't built yet but we have our eyes on it as your are not the first one to bring that up. You can use Hookdeck in front of lamda and to the transformation there, you'd still get the benefit of async processing, retries, etc

This is the way to go and I'd love to see more API's with robust events endpoint for polling & reconciliation. Deletes are especially hard to reconcile with many APIs since they aren't queryable and you need to instance check if every ID still exist. Shopify I'm looking at you.

I partially agree but the issue with relying on the producer delivery is that you effectively give up control on what the retry logic is. If it doesn't fit your use case, too bad for you. While ideally every platform would provide those configuration I think it's unreasonable to think all platforms will offer excellent webhook tools & configuration. You better just take things under your own hands.