Saas (microsass?) based around webhooks

Hi Justin,

It's great idea and in fact, that's exactly what we have built at hookdeck.io.

As you point out, most many team end up spending time putting together what we call 'webhook infrastructure' to handle their events. That usually means setting up ingestion servers (often AWS Lamda's), queues, storage, alerting and logging etc. We've built Hookdeck to replace all of this without deploying any infrastructure with the idea of being production ready with very little work.

You can learn more about how that works right here: https://hookdeck.io/docs

It's a topic I don't see being brought often on IH, HN and others, I'm glad to see more people like you are talking about it 🤩

Shoot me an email and we can discuss some more about it! [email protected]

I believe Zapier solves this isssue

A few reasons why I wouldn't use this kind of product:

• It's one more piece in the puzzle, i.e. one more thing that can fail. Webhooks are often very important (e.g. when you need to change the status of a subscription if a payment fails or something) and I wouldn't want to risk webhook alerts because something in the middle is having some downtime;
• privacy and security: some webhook alerts may carry sensitive data that can't or shouldn't be shared with third parties, especially in GDPR land; also people would have to trust you with this data, which isn't easy;
• many services already have a retry logic for when something goes wrong when connecting to your backend; they usually retry every a number of times with exponential backoff. A couple of examples are Chargebee and Paddle that I have used or use for Payments. I can't remember Chargebee but Paddle even allows you to retry the webhooks from their control panel if needed;
• in most cases, at least from my experience, webhooks need to be integrated with the business logic of my product, so adding something in the middle might just make things more complicated;
• some services use some particular mechanisms for authentication when posting webhooks; Paddle for example uses some particular signature that must be used by my backend when parsing the data received with the webhook. Unless your service simply proxies/forwards the webhook requests exactly as they are, some custom logic would have to be implemented on your side, which isn't scalable with so many services that use webhooks.

These are just some random reasons that come to my mind right away. I wouldn't use such a service and I wouldn't pursue this as a business to be honest. I don't really see the point if I can be honest :)

Not much to add here but just want to say that one of my favourite free (with paid option) webhook-related tools is http://webhook.site/

It simply helps expose webhook payloads, for when you are testing things.

Might provide a bit of inspiration!

I have been building something similar for several years now (https://webhookrelay.com/) :) It's mostly my main side project (doing consulting on ML/Data Science full-time). The problems are interesting that such services need to solve, that's why I really like working on it.

Mostly:

• Handling really high numbers of webhook (not surprising :D) and normal databases like postgres/mysql kinda go into meltdown with you are inserting so much data and then need to do some timeseries querying. You have to go with more interesting database choices.
• Messaging between the nodes
• Handling slow consumers (this might not look like an issue early on but later it becomes a proper PITA that deserves a blog post)

It's kinda like a never ending project tbh. I have several other projects started around IoT fleet management and a public transport ticketing service. Not sure which one will be the most successful yet. (so far consulting pays the best :D )

I develop shopify apps and I need to listen to new order webhooks. Many app developers also need to listen to various webhooks as u mentioned.

Some developers suggest to use aws lambda to build a queue system. But I am not familiar with aws. It'd too enterprises for me.

I think about using celery + redis but it's too complicated to set up. The 3rd way may be using DO app platform so it's scalable.

If you can set up a webhook service with HA, scalable (due to peak seasons) and a freemium pricing (like sentry), it may be attractive.

I dont launch my app yet so I simply handle the webhooks with a docker container.

Just have in mind that there are already established services doing what you described. For example https://pipedream.com does that and more.

As @ssijak said, there's already an established service doing what you described.

I recently had to integrate third-party API for one of my clients using web hooks and I'd rather use something that's already established for something as critical as this (my client landed $20k/month customer that REQUIRED this integration).

But on the positive side, you can find users that are dissatisfied with Pipedream and make something for them.

I remember seeing this exact business a few days ago: https://gowebhooks.github.io/