20 ms·

Show HN: Diahook – Webhooks as a Service

217 points by tasn 6y ago

artembugara 6y ago
Hi Tom! It sounds great. At NewsCatcher [1] we've been asked for webhooks to our data a few times. We still did not start the implementation. Do you think Diahook would be a good solution to consider? Also, 1$ per 1,000 hooks. What exactly does it mean? Like any push through your hook? [1] newscatcherapi.com
- tasn 6y ago
  Yeah, I know the feeling, haha. It's $1 per 1,000 messages. Retries, or if there's no one to send to are free. So it's just for actual webhooks sent. I'll clarify it now. Anyhow, I'd love to chat and help you get started, please email me at tom @ the domain!
  - artembugara 6y ago
    That may be my bad. In my head "webhook" is a process. And you do all those pushes through this "webhook". Doesn't mean I'm right.
    - tasn 6y ago
      Yeah, you are probably right and the writing is sloppy. I was going to fix it, but I just saw we have an explanation under the pricing boxes. Does that clarify things?
      - artembugara 6y ago
        Yeah, I missed it. I'd prefer it to be under the Title of the section: "Diahook Pricing"
        tasn 6y ago
        Will think about reorganising it, thanks!
wyc 6y ago
I can't remember how many times I've written Redis-backed retry timers in Go to handle unreliable endpoints. It'd be great to not have to do that again. I like that you're focusing on such a concrete problem that I can see shaped functionality need into which it fits. What happens when the requests to your API fail? Do I need to retry? Will there be an SDK that can help with this?
- tasn 6y ago
  Hahaha yeah, I hope no one ever needs to do it ever again! It's a good question, and I answered it in a sibling comment: https://news.ycombinator.com/item?id=26400510 https://news.ycombinator.com/item?id=26400510 Essentially I think it's a risk with any external API you use. What happens when Stripe goes down? Twilio? Sendgrid (when you use magic links login)? Our whole focus is uptime, that's what we do. :)
- mperham 6y ago
  This is one of the advantages of using background jobs. Any call to a 3rd party service should be in the background to handle network and reliability issues. The job system handles automatic retry.
tasn 6y ago
Hey everyone, my name is Tom, and I'm excited to be launching Diahook on HN! Diahook makes it easy for developers to send webhooks. Developers make one API call and we take care of deliverability, retries, and offer a great developer experience for their users. Essentially, we make it possible for everyone to offer a Stripe-like webhooks experience. At my previous company, our users were constantly asking us for webhooks, both for consuming in their own services and for integrations with no-code solutions like Zapier. However, we kept on deferring building them because we weren't willing to commit the engineering time, resources and ongoing maintenance required of a webhook delivery system. There are a variety of challenges when it comes to sending webhooks. For example customer endpoints fail or hang much more often than you would think, so you need to implement retries, but also make sure that such failures don't slow down or block your send queue or the rest of your system. Additionally, because of how webhooks work, anyone can send fake webhooks to your customers, so you need to make sure to cryptographically sign the payload, and make it easy for your users to verify it. You also want to avoid overloading your users' endpoints, so you want to automatically rate-limit webhook sending, as well as disabling failing ones, and notifying your users when you do. I love webhooks, and I think everyone should be offering them! Our goal with Diahook is to make it faster for developers to add webhooks to their service, take care of the above challenges (and more), relieve them of having to worry about maintenance and scaling, and offer their users a UI for inspecting, debugging and replaying of past webhooks out of the box. I'd love to hear about your experience building (or using) webhooks systems. What's a must have? Any war stories to share? Got any questions? Suggestions? Please let me know! Docs: https://www.diahook.com/docs/ https://www.diahook.com/docs/ API viewer (and OpenAPI specs): https://api.diahook.com/docs/ https://api.diahook.com/docs/
- macspoofing 6y ago
  >Developers make one API call and we take care of deliverability, retries Don't developers need to handle deliverability and retries to Diahook?
  - dariusj18 6y ago
    Agree, I feel like anything like this as a service can be helpful, but misses the mark on use case.
kevsim 6y ago
We connected with Tom just as we were getting ready to build webhooks into our product (Kitemaker W21). We had a few teams asking for webhooks but didn’t have much time to dedicate to it right now so we were in the market for something like Diahook. It ended up taking us one afternoon (this afternoon in fact!) to integrate Diahook. Was super straightforward and Tom was highly responsive.
- tasn 6y ago
  Haha, yeah, was lucky timing. :)
mrkurt 6y ago
This is great. I've wanted a library for this, but a SaaS will do. :)
- tasn 6y ago
  Half of the magic is in the infra (scalability, monitoring, and etc), so we can't deliver the same value with just a library. Though I would love to hear what you have in mind! P.S, what you are doing with Fly.io is super cool!
  - mrkurt 6y ago
    Hey thanks! If you want to run Diahook on it we can help. We happen to be pretty good at infra, so a library / self hosted setup is usually preferable. This is partially because we prefer to monitor things ourselves, and partially because we don't want to send things like auth tokens through a third party service. We might be unique, though.
    - tasn 6y ago
      Thanks, I'll keep it in mind when we are ready! I especially like the easy postgres replication. :) I'll reach out about Diahook, as we can also have a self-hosted offering, and I think it could still make sense for you. As you can still benefit from the rest of the offering, including client side libraries and management UI (will be fully customisable soon).
  - stunt 6y ago
    I've built a serverless webhook dispatcher at my previous job and you can actually cover most of the scalability and resiliency requirements with a few AWS services. I think what is hard to build and the core value that your service provides is the management, governance, and monitoring around it. I would focus there as the main selling point. Kudos for launching it and good luck.
lyonlim 6y ago
This is a great idea, congrats! We could definitely use this, although I’m cautious about passing our customer data through yet another data processor.
- tasn 6y ago
  Your concern is fair, and I wish more companies were as responsible about their user data as you are! I'm actually very privacy conscious myself, which is why we plan on offering optional end-to-end encryption in the very near future. This way only you and your customers can access the data, not us. :) Our libraries will deal with the encryption/decryption for you.
lyime 6y ago
The real value creation here would be turning a GET API endpoint into a webhook service. So your service would monitor the service and push updates on changes / diffs based on certain time interval. Build that and people will flock to you.
- tasn 6y ago
  Zapier does it to an extent, but yeah, it's something to keep in mind. You got my creative juices flowing a bit with this comment, thanks a lot!
  - lyime 6y ago
    Awesome! Congrats on shipping. We launched Terminal49 APIs with webhooks as first class citizen. So this is top of mind. There are many industries where push APIs haven't caught up and are much needed. Let me know if I can help akshay@terminal49.com
- fasteo 6y ago
  If I am understanding you well, fanout[1] will serve this purpose [1] https://fanout.io/ https://fanout.io/
  - jkarneges 6y ago
    Fanout founder here! I appreciate the mention, although we don't actually support sending webhooks. Well, awhile back we did, but lately we only support pushing to client-initiated connections.
- dwwoelfel 6y ago
  You can do this with OneGraph (https://www.onegraph.com https://www.onegraph.com) via our `poll` subscription. Here's an example query that will poll an npm package and send a payload whenever the latest version changes. https://www.onegraph.com/graphiql?shortenedId=FYH1SY https://www.onegraph.com/graphiql?shortenedId=FYH1SY subscription PollNpmPackage { poll( webhookUrl: "https://example.com" onlyTriggerWhenPayloadChanged: true schedule: { every: { minutes: 60 } } ) { query { npm { package(name: "graphql") { distTags { latest { versionString } } } } } } } This is just an illustrative example. I used NPM because it doesn't require any authorization. We also support proper subscriptions for NPM that listen to their couchdb change feed.
jackconsidine 6y ago
Spent so much time rolling my own webhook system for my eSign side project [0]- there are so many edge cases and thorny behaviors. This is a rare perfect fit of a SaaS offering. I can't wait to integrate with some of my other projects! The pricing model is generous as well. [0] https://waiverstevie.com https://waiverstevie.com
- tasn 6y ago
  Thanks a lot for your kind words! Please feel free to reach out at tom @ the domain. Happy to help you get started, and I'm super interested in hearing about your other projects!
progx 6y ago
This is great if it has a better uptime than the service that receive the message. On the other hand: now we have 2 Services that could crash and our app still need a retry logic. Or we could use it as a fallback, if our services is down, we sent to Diahook.
- tasn 6y ago
  Our whole focus is uptime, and I think it's similar to how you use other APIs in your service, how do you deal when you can't reach them? With that being said, this is something we plan on helping with too. We will have retries to different endpoints (in different geographies), and ways to easily implement it locally. We already offer idempotentcy so that helps.
  - macspoofing 6y ago
    >Our whole focus is uptime At some point you're going to have to quantify that and provide enough evidence (of one sort or another) for this claim to be credible. After all, every service under the sun will claim things like 'scalability', 'performance', 'uptime', 'resiliency', whatever. Devil is in the details.
    - tasn 6y ago
      I completely agree. We are still new and we need to earn this over time. Our uptime so far is 100%, but that's easy to achieve as a new company... :) This is something we focus on though, and as part of this focus, we will focus on earning this trust and making it as transparent as we can.
      - macspoofing 6y ago
        >This is something we focus on though I don't want to nitpick but ... are you really 'focused' on this? You're a startup with limited resources trying to get a product up and running with commercially-viable feature-set. You're not setup for high availability. You just aren't. Proper HA is very hard and as you climb the '9s' in uptime, you introduce huge amount of complexity, cost, planning and manpower - which is something you haven't done and can't do as a startup and, honestly, it isn't worth to do for a Webhook SaaS. And that's OK! The nice thing about Webhooks is that nobody runs mission-critical workflows with them because there is an implicit expectation of unreliability. This means that for HA/uptime you just need something reasonable. Your service may not survive an AWS outage (or whatever cloud service or datacenter you're deployed in) or a directed DDOS attack, but if your infrastructure can handle traffic spikes and occasional node going down - you're golden.
alexbouchard 6y ago
Nice work! I'm just glad to see more people in the space and there has been very little pressure on platforms to offer good webhooks, many integrations are pretty barebone and I hope you manage to help with that. We've also been building https://hookdeck.io https://hookdeck.io which is tackling a related problem but for incoming webhooks instead of outgoing. Receiving webhooks at scale reliably requires a lot of work and well-thought-out infrastructure. I'm just about to do a Show HN of our own. I'll reach out to you!
- tasn 6y ago
  Thanks! Happy to help if I can, feel free to reach out! Email: tom @ the domain.
  - alexbouchard 6y ago
    Saw that a second too late, sent to contact @
    - tasn 6y ago
      Got it!
maratc 6y ago
GitHub sends webhooks to our Jenkins servers, but sometimes services on our side are down. Can we use your service as an intermediary to ensure delivery?
- tasn 6y ago
  We don't do it at the moment, but reach out to me at tom @ the domain, I'd be happy to chat.
- alexbouchard 6y ago
  I can't say for Diahook but https://hookdeck.io https://hookdeck.io was built for this. (Disc: Co-Founder)
jabo 6y ago
A go-to architecture topic of mine for backend engineer interviews is to design a webhook system (the push side). I’ve gotten a lot of mileage out of it because depending on the person’s experience dealing with a running production system, I’d get varying level of detail unprompted and that usually is a nice proxy for depth of experience. It turns out my interview question is now a SaaS! Kudos on the launch OP. This is a much needed service and it’s one of those things that once you see exist you go d’oh, why didn’t we have something like this all this while.
- tasn 6y ago
  I'm stealing this interview question, haha. :P Thanks a lot, yeah, there are so many moving parts and pitfalls. I think that what makes it a good question, also makes it a good service (I hope).
- spullara 6y ago
  Square had a similar interview question but it was more along the lines of how to keep a socket open to a financial services company. Lots of the same issues.
redisman 6y ago
Looks great! Sorry for the off-topic but what is the "2021 bootstrap" that all startup landing pages are using? I like the look and keep seeing it everywhere
- tasn 6y ago
  Haha, it is self designed (but using bootstrap).
- dmlittle 6y ago
  I think it's probably the unDraw[1] illustrations you're seeing and not the theme itself. [1] https://undraw.co/illustrations https://undraw.co/illustrations
  - redisman 6y ago
    That’s definitely a part of it. Thanks
  - tasn 6y ago
    Oh yeah, I forgot about undraw! I thought he was talking about the layout.
joantune 6y ago
I use Google Cloud Tasks for at least some of the same purpose(s) I wonder how this one stacks up given is centered for webhooks specifically
- tasn 6y ago
  We take care of related webhooks channels. We touched on some of them on the landing page, but, in no particular order: Deliverability, monitoring, retries, security (signing), a nice UI for your users to debug, inspect and etc. :)
oliverx0 6y ago
There is something really cool about this. It is the kind of service I think I could implement if I invested enough time, but at the same time since you are taking care of all edge cases and just provide it as a service with such a simple interface, I'd rather just pay for it! Will definitely be using this on my projects. Congrats!
- tasn 6y ago
  Thanks for the kind words! Yeah, there is no magic (well, there is some), it's just the product of experience and hard work. We make it so you don't have to earn this experience the hard way, and not have to waste your time on doing the grunt work. :)
jkarneges 6y ago
Good to see this being addressed! We used to offer webhooks-as-a-service at Fanout, but it wasn't very popular and last year we discontinued the feature. There are several reasons I believe we weren't successful with it: 1) There is a perception that webhooks are "easy", and so developers might not even think to look for a solution. After all, anyone can send an HTTP request. The devil is in the details of course, and a good webhooks system is actually a lot of work. 2) I believe most devs looking for a "push" solution are usually looking for something like WebSockets (which has a more common perception of being hard). And so the people finding us or landing on our page had a specific goal in mind, and our additional offering of webhooks wasn't enticing. 3) Our webhooks feature simply wasn't that good. It handled retries, fan-out, rate limiting, ordered delivery, and full payload customization. That's a start, but a complete solution also needs inspection, response feedback, test calls, and UI widget. With the right product and GTM, maybe it can work. Good luck!
- tasn 6y ago
  Thank you, I'd love to chat if you are willing! My email is tom @ the domain. Is there a way I could reach you? Thanks!
  - jkarneges 6y ago
    Sent you a mail.
    - tasn 6y ago
      Cheers, thanks!
matdehaast 6y ago
This is great! Pinged my team and they like it. Some notes: 1) I think you are to cheap. 2) signatures of sent webhooks is pretty important for the receiving party.
- tasn 6y ago
  Thanks for the feedback! Happy to chat with them directly (email: tom @ the domain). 1. Ah, maybe. We are still new and trying to figure it out. Thanks for the feedback. 2. We already offer them, including libraries for some languages to easily verify them!
kenrose 6y ago
Similar questions from last time there was a Webhooks as a Service on HN [1] 1. How do you deal with endpoints that are down or 500'ing? What kind of retry policy or backoff occurs? Related, how do you notify clients when their endpoints are having trouble? (I ask because that's PII that I then have to share with you). 2. Is there support for message signing (e.g., HMAC) to let clients verify that the webhook really came from us? How does it work? 3. Any kind of deduplication support? One use case we had was that certain webhooks only required the latest delivery. e.g., product inventory. If we previously failed to deliver a webhook, but have a newer version pending, our next attempt should try to send the newest version. 4. Is it possible to delay hydrating data in the payload? It seems the expected usage is that I send a blob of data and you take care of the last mile and send it. Is it possible to send you an id and then you call back to my service and fetch the latest version of that object just before delivery? 5. How are webhook subscriptions actually managed? e.g., my app lets users register webhook URLs? How do I get those URLs to your service? 6. The big question: What do I do if your service is down? [1] - https://news.ycombinator.com/item?id=25992800 https://news.ycombinator.com/item?id=25992800
- tasn 6y ago
  Thanks for asking: 1. Exponential backoff. We don't notify clients, but we notify you with a webhook. We actually don't have it implemented yet, but will have in the next week or two. 2. Yes, and libraries for some languages (more coming) to easily verify it. See the docs for how it works, but standard stuff. We also plan on offering end-to-end encryption in the very near future so that we can't even access your payloads. 3. No, and no plans for supporting it for now. Does anyone do it? I think sending all of them is actually a feature. 4. Could you elaborate? You mean changing the webhook content in each attempt? No plan at the moment. Similar to the previous point. We consider webhook payloads as immutable messages. 5. You can either use our API to add them, or redirect users to a management UI we built with a one-time password. We will also offer JS libraries to make it easy to build your own UI. 6. I answered it a few times in this thread. Here's my original sloppy comment (with a link to a comment with more context): https://news.ycombinator.com/item?id=26400510 https://news.ycombinator.com/item?id=26400510
dgudkov 6y ago
@tasn, do you have a client library? PS. On a side note, it would be very nice to have a standard for webhooks similarly to OAuth. We're designing a solution for accepting various webhooks and the variety of negotiation schemes required by various cloud services is absolutely counter-productive.
- tasn 6y ago
  Yeah we do. Only for Python and JS (TypeScript) at the moment, but we will add more. Both for the sending part (it's really just a REST API under the hood for now), and the consuming (verifying signatures).
ianstormtaylor 6y ago
Extremely good idea. I've had to implement webhooks in the past and it was a huge pain (and my implementation likely had tons of bugs anyways). Turning into a well architected service seems like a perfect fit. Congrats on the launch and good luck!
- tasn 6y ago
  Thanks a lot!
owaislone 6y ago
This looks nice but don't I still have to invest all the engineering to make sure my calls reach Diahook service in the first place? The argument from diahook seems to be "we'll never go down". That's covered by SLAs by all companies that Diahook would be forwarding my calls to. Does Diahook claim 100% uptime? That's impossible. Even if it were possible, there are many other points of failure between my service and Diahook and I need to take all of them into account. Once I do that, I don't see much point in using Diahook. This would've been better off as a library I think. There are other features/reason that would make me use a "webhook service" and I've contemplated building one before but mainly for async message passing between systems. Anything sync and you almost always need to take care of all the failure states. This could be useful as a library or side-car. I can't help but think of this as a plugin for something like Envoy even though Envoy probably does a lot of this already.
- tasn 6y ago
  Hey, thanks for the feedback! We don't claim 100% SLA, as you said, it's impossible. I already replied to this a few times in this thread. I think the same can be said on every other API company, including Stripe, Sendgrid, Twilio and etc. If this is a concern for you, you need to take care of that, if it's not a concern for you, then Diahook is not any different. Anyhow, we take of other things other than just deliverability. We sign the webhooks for you to prevent SSRF, we implemented a retry logic, we have monitoring on all of these, and all of the other things I mentioned elsewhere. I mentioned it elsewhere in this thread, I don't see how this can be a library. It's a standalone service that needs to be run and monitored, needs to scale with your usage, and you need to make sure it doesn't hang, the queue doesn't get too long, and etc. I actually say it in the post, webhooks aren't as simple as they seem.
  - vgel 6y ago
    It seems to me that people saying your service is also potentially unreliable are missing the point a bit. By paying you money, there's a customer relationship, an SLA, etc. As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down, but I do get an SLA from Diahook.
GhvstCode 6y ago
Hey, This is an amazing product! Congratulations on the launch. At Hookdeck(hookdeck.io), we are solving a similar problem. Hookdeck sits between the API provider & your service, ensuring you never miss a webhook notification. We provide the queues for reliable webhook ingestion and the tooling for easy monitoring and troubleshooting, Automatic & manual retries, event filtering. You should check us out
- tasn 6y ago
  Thanks a lot! And yeah, I'm familiar with hookdeck, your co-founder already commented in this thread. :)
deleted 6y ago
[deleted]
kondro 6y ago
Does this have any relationship with https://www.etesync.com/ https://www.etesync.com/ and https://www.etebase.com/ https://www.etebase.com/ ?
- tasn 6y ago
  Same creator (me), but otherwise no. :)
xrd 6y ago
The page says backed by YC, right? Are you from a YC batch?
- tasn 6y ago
  Yeah, YC W21!
edoceo 6y ago
Will this make it easier to share from my phone to my own we hook service?
- tasn 6y ago
  Not sure I follow. Could you please elaborate?
runako 6y ago
This is cool! One problem I've run into with Webhooks in the past is not being able to audit every call after the fact. I want to be able to see which endpoints were called, when, with what payloads (logs scrubbed of PII etc.). This information is invaluable in responding to support queries. Good luck!
- tasn 6y ago
  We have the ability to audit and inspect past calls. We don't yet scrub PII, though we have a few features down the pipeline that will enable just that. Thanks for your comment!
rozenmd 6y ago
This looks awesome - I'm in the middle of building https://onlineornot.com https://onlineornot.com and was just about to put the webhook functionality on hold for a bit before seeing this
- tasn 6y ago
  Hehe, I know this story too well, I've been there before! Feel free to reach out (email: tom @ the domain) if you have any questions or need any help! Oh, and please share feedback.
ezekg 6y ago
This is very cool. I scratched down "webhooks-as-a-service" into my "business ideas" note years ago after building my own webhook system for keygen.sh (mine is backed by Redis+Sidekiq). Lots of edge cases over the years. Glad somebody is running with the idea!
- tasn 6y ago
  Thank you. :)

217 points by tasn 6y ago

Hi Tom! It sounds great. At NewsCatcher [1] we've been asked for webhooks to our data a few times. We still did not start the implementation. Do you think Diahook would be a good solution to consider? Also, 1$ per 1,000 hooks. What exactly does it mean? Like any push through your hook? [1] newscatcherapi.com

tasn 6y ago
Yeah, I know the feeling, haha. It's $1 per 1,000 messages. Retries, or if there's no one to send to are free. So it's just for actual webhooks sent. I'll clarify it now. Anyhow, I'd love to chat and help you get started, please email me at tom @ the domain!
- artembugara 6y ago
  That may be my bad. In my head "webhook" is a process. And you do all those pushes through this "webhook". Doesn't mean I'm right.
  - tasn 6y ago
    Yeah, you are probably right and the writing is sloppy. I was going to fix it, but I just saw we have an explanation under the pricing boxes. Does that clarify things?
    - artembugara 6y ago
      Yeah, I missed it. I'd prefer it to be under the Title of the section: "Diahook Pricing"
      - tasn 6y ago
        Will think about reorganising it, thanks!

wyc 6y ago

I can't remember how many times I've written Redis-backed retry timers in Go to handle unreliable endpoints. It'd be great to not have to do that again. I like that you're focusing on such a concrete problem that I can see shaped functionality need into which it fits. What happens when the requests to your API fail? Do I need to retry? Will there be an SDK that can help with this?

tasn 6y ago
Hahaha yeah, I hope no one ever needs to do it ever again! It's a good question, and I answered it in a sibling comment: https://news.ycombinator.com/item?id=26400510 https://news.ycombinator.com/item?id=26400510 Essentially I think it's a risk with any external API you use. What happens when Stripe goes down? Twilio? Sendgrid (when you use magic links login)? Our whole focus is uptime, that's what we do. :)
mperham 6y ago
This is one of the advantages of using background jobs. Any call to a 3rd party service should be in the background to handle network and reliability issues. The job system handles automatic retry.

tasn 6y ago

Hey everyone, my name is Tom, and I'm excited to be launching Diahook on HN! Diahook makes it easy for developers to send webhooks. Developers make one API call and we take care of deliverability, retries, and offer a great developer experience for their users. Essentially, we make it possible for everyone to offer a Stripe-like webhooks experience. At my previous company, our users were constantly asking us for webhooks, both for consuming in their own services and for integrations with no-code solutions like Zapier. However, we kept on deferring building them because we weren't willing to commit the engineering time, resources and ongoing maintenance required of a webhook delivery system. There are a variety of challenges when it comes to sending webhooks. For example customer endpoints fail or hang much more often than you would think, so you need to implement retries, but also make sure that such failures don't slow down or block your send queue or the rest of your system. Additionally, because of how webhooks work, anyone can send fake webhooks to your customers, so you need to make sure to cryptographically sign the payload, and make it easy for your users to verify it. You also want to avoid overloading your users' endpoints, so you want to automatically rate-limit webhook sending, as well as disabling failing ones, and notifying your users when you do. I love webhooks, and I think everyone should be offering them! Our goal with Diahook is to make it faster for developers to add webhooks to their service, take care of the above challenges (and more), relieve them of having to worry about maintenance and scaling, and offer their users a UI for inspecting, debugging and replaying of past webhooks out of the box. I'd love to hear about your experience building (or using) webhooks systems. What's a must have? Any war stories to share? Got any questions? Suggestions? Please let me know! Docs: https://www.diahook.com/docs/ https://www.diahook.com/docs/ API viewer (and OpenAPI specs): https://api.diahook.com/docs/ https://api.diahook.com/docs/

macspoofing 6y ago
>Developers make one API call and we take care of deliverability, retries Don't developers need to handle deliverability and retries to Diahook?
- dariusj18 6y ago
  Agree, I feel like anything like this as a service can be helpful, but misses the mark on use case.

kevsim 6y ago

We connected with Tom just as we were getting ready to build webhooks into our product (Kitemaker W21). We had a few teams asking for webhooks but didn’t have much time to dedicate to it right now so we were in the market for something like Diahook. It ended up taking us one afternoon (this afternoon in fact!) to integrate Diahook. Was super straightforward and Tom was highly responsive.

tasn 6y ago
Haha, yeah, was lucky timing. :)

mrkurt 6y ago

This is great. I've wanted a library for this, but a SaaS will do. :)

tasn 6y ago
Half of the magic is in the infra (scalability, monitoring, and etc), so we can't deliver the same value with just a library. Though I would love to hear what you have in mind! P.S, what you are doing with Fly.io is super cool!
- mrkurt 6y ago
  Hey thanks! If you want to run Diahook on it we can help. We happen to be pretty good at infra, so a library / self hosted setup is usually preferable. This is partially because we prefer to monitor things ourselves, and partially because we don't want to send things like auth tokens through a third party service. We might be unique, though.
  - tasn 6y ago
    Thanks, I'll keep it in mind when we are ready! I especially like the easy postgres replication. :) I'll reach out about Diahook, as we can also have a self-hosted offering, and I think it could still make sense for you. As you can still benefit from the rest of the offering, including client side libraries and management UI (will be fully customisable soon).
- stunt 6y ago
  I've built a serverless webhook dispatcher at my previous job and you can actually cover most of the scalability and resiliency requirements with a few AWS services. I think what is hard to build and the core value that your service provides is the management, governance, and monitoring around it. I would focus there as the main selling point. Kudos for launching it and good luck.

lyonlim 6y ago

This is a great idea, congrats! We could definitely use this, although I’m cautious about passing our customer data through yet another data processor.

tasn 6y ago
Your concern is fair, and I wish more companies were as responsible about their user data as you are! I'm actually very privacy conscious myself, which is why we plan on offering optional end-to-end encryption in the very near future. This way only you and your customers can access the data, not us. :) Our libraries will deal with the encryption/decryption for you.

lyime 6y ago

The real value creation here would be turning a GET API endpoint into a webhook service. So your service would monitor the service and push updates on changes / diffs based on certain time interval. Build that and people will flock to you.

tasn 6y ago
Zapier does it to an extent, but yeah, it's something to keep in mind. You got my creative juices flowing a bit with this comment, thanks a lot!
- lyime 6y ago
  Awesome! Congrats on shipping. We launched Terminal49 APIs with webhooks as first class citizen. So this is top of mind. There are many industries where push APIs haven't caught up and are much needed. Let me know if I can help akshay@terminal49.com
fasteo 6y ago
If I am understanding you well, fanout[1] will serve this purpose [1] https://fanout.io/ https://fanout.io/
- jkarneges 6y ago
  Fanout founder here! I appreciate the mention, although we don't actually support sending webhooks. Well, awhile back we did, but lately we only support pushing to client-initiated connections.
dwwoelfel 6y ago
You can do this with OneGraph (https://www.onegraph.com https://www.onegraph.com) via our `poll` subscription. Here's an example query that will poll an npm package and send a payload whenever the latest version changes. https://www.onegraph.com/graphiql?shortenedId=FYH1SY https://www.onegraph.com/graphiql?shortenedId=FYH1SY subscription PollNpmPackage { poll( webhookUrl: "https://example.com" onlyTriggerWhenPayloadChanged: true schedule: { every: { minutes: 60 } } ) { query { npm { package(name: "graphql") { distTags { latest { versionString } } } } } } } This is just an illustrative example. I used NPM because it doesn't require any authorization. We also support proper subscriptions for NPM that listen to their couchdb change feed.

jackconsidine 6y ago

Spent so much time rolling my own webhook system for my eSign side project [0]- there are so many edge cases and thorny behaviors. This is a rare perfect fit of a SaaS offering. I can't wait to integrate with some of my other projects! The pricing model is generous as well. [0] https://waiverstevie.com https://waiverstevie.com

tasn 6y ago
Thanks a lot for your kind words! Please feel free to reach out at tom @ the domain. Happy to help you get started, and I'm super interested in hearing about your other projects!

progx 6y ago

This is great if it has a better uptime than the service that receive the message. On the other hand: now we have 2 Services that could crash and our app still need a retry logic. Or we could use it as a fallback, if our services is down, we sent to Diahook.

tasn 6y ago
Our whole focus is uptime, and I think it's similar to how you use other APIs in your service, how do you deal when you can't reach them? With that being said, this is something we plan on helping with too. We will have retries to different endpoints (in different geographies), and ways to easily implement it locally. We already offer idempotentcy so that helps.
- macspoofing 6y ago
  >Our whole focus is uptime At some point you're going to have to quantify that and provide enough evidence (of one sort or another) for this claim to be credible. After all, every service under the sun will claim things like 'scalability', 'performance', 'uptime', 'resiliency', whatever. Devil is in the details.
  - tasn 6y ago
    I completely agree. We are still new and we need to earn this over time. Our uptime so far is 100%, but that's easy to achieve as a new company... :) This is something we focus on though, and as part of this focus, we will focus on earning this trust and making it as transparent as we can.
    - macspoofing 6y ago
      >This is something we focus on though I don't want to nitpick but ... are you really 'focused' on this? You're a startup with limited resources trying to get a product up and running with commercially-viable feature-set. You're not setup for high availability. You just aren't. Proper HA is very hard and as you climb the '9s' in uptime, you introduce huge amount of complexity, cost, planning and manpower - which is something you haven't done and can't do as a startup and, honestly, it isn't worth to do for a Webhook SaaS. And that's OK! The nice thing about Webhooks is that nobody runs mission-critical workflows with them because there is an implicit expectation of unreliability. This means that for HA/uptime you just need something reasonable. Your service may not survive an AWS outage (or whatever cloud service or datacenter you're deployed in) or a directed DDOS attack, but if your infrastructure can handle traffic spikes and occasional node going down - you're golden.

alexbouchard 6y ago

Nice work! I'm just glad to see more people in the space and there has been very little pressure on platforms to offer good webhooks, many integrations are pretty barebone and I hope you manage to help with that. We've also been building https://hookdeck.io https://hookdeck.io which is tackling a related problem but for incoming webhooks instead of outgoing. Receiving webhooks at scale reliably requires a lot of work and well-thought-out infrastructure. I'm just about to do a Show HN of our own. I'll reach out to you!

tasn 6y ago
Thanks! Happy to help if I can, feel free to reach out! Email: tom @ the domain.
- alexbouchard 6y ago
  Saw that a second too late, sent to contact @
  - tasn 6y ago
    Got it!

maratc 6y ago

GitHub sends webhooks to our Jenkins servers, but sometimes services on our side are down. Can we use your service as an intermediary to ensure delivery?

tasn 6y ago
We don't do it at the moment, but reach out to me at tom @ the domain, I'd be happy to chat.
alexbouchard 6y ago
I can't say for Diahook but https://hookdeck.io https://hookdeck.io was built for this. (Disc: Co-Founder)

jabo 6y ago

A go-to architecture topic of mine for backend engineer interviews is to design a webhook system (the push side). I’ve gotten a lot of mileage out of it because depending on the person’s experience dealing with a running production system, I’d get varying level of detail unprompted and that usually is a nice proxy for depth of experience. It turns out my interview question is now a SaaS! Kudos on the launch OP. This is a much needed service and it’s one of those things that once you see exist you go d’oh, why didn’t we have something like this all this while.

tasn 6y ago
I'm stealing this interview question, haha. :P Thanks a lot, yeah, there are so many moving parts and pitfalls. I think that what makes it a good question, also makes it a good service (I hope).
spullara 6y ago
Square had a similar interview question but it was more along the lines of how to keep a socket open to a financial services company. Lots of the same issues.

redisman 6y ago

Looks great! Sorry for the off-topic but what is the "2021 bootstrap" that all startup landing pages are using? I like the look and keep seeing it everywhere

tasn 6y ago
Haha, it is self designed (but using bootstrap).
dmlittle 6y ago
I think it's probably the unDraw[1] illustrations you're seeing and not the theme itself. [1] https://undraw.co/illustrations https://undraw.co/illustrations
- redisman 6y ago
  That’s definitely a part of it. Thanks
- tasn 6y ago
  Oh yeah, I forgot about undraw! I thought he was talking about the layout.

joantune 6y ago

I use Google Cloud Tasks for at least some of the same purpose(s) I wonder how this one stacks up given is centered for webhooks specifically

tasn 6y ago
We take care of related webhooks channels. We touched on some of them on the landing page, but, in no particular order: Deliverability, monitoring, retries, security (signing), a nice UI for your users to debug, inspect and etc. :)

oliverx0 6y ago

There is something really cool about this. It is the kind of service I think I could implement if I invested enough time, but at the same time since you are taking care of all edge cases and just provide it as a service with such a simple interface, I'd rather just pay for it! Will definitely be using this on my projects. Congrats!

tasn 6y ago
Thanks for the kind words! Yeah, there is no magic (well, there is some), it's just the product of experience and hard work. We make it so you don't have to earn this experience the hard way, and not have to waste your time on doing the grunt work. :)

jkarneges 6y ago

Good to see this being addressed! We used to offer webhooks-as-a-service at Fanout, but it wasn't very popular and last year we discontinued the feature. There are several reasons I believe we weren't successful with it: 1) There is a perception that webhooks are "easy", and so developers might not even think to look for a solution. After all, anyone can send an HTTP request. The devil is in the details of course, and a good webhooks system is actually a lot of work. 2) I believe most devs looking for a "push" solution are usually looking for something like WebSockets (which has a more common perception of being hard). And so the people finding us or landing on our page had a specific goal in mind, and our additional offering of webhooks wasn't enticing. 3) Our webhooks feature simply wasn't that good. It handled retries, fan-out, rate limiting, ordered delivery, and full payload customization. That's a start, but a complete solution also needs inspection, response feedback, test calls, and UI widget. With the right product and GTM, maybe it can work. Good luck!

tasn 6y ago
Thank you, I'd love to chat if you are willing! My email is tom @ the domain. Is there a way I could reach you? Thanks!
- jkarneges 6y ago
  Sent you a mail.
  - tasn 6y ago
    Cheers, thanks!

matdehaast 6y ago

This is great! Pinged my team and they like it. Some notes: 1) I think you are to cheap. 2) signatures of sent webhooks is pretty important for the receiving party.

tasn 6y ago
Thanks for the feedback! Happy to chat with them directly (email: tom @ the domain). 1. Ah, maybe. We are still new and trying to figure it out. Thanks for the feedback. 2. We already offer them, including libraries for some languages to easily verify them!

kenrose 6y ago

Similar questions from last time there was a Webhooks as a Service on HN [1] 1. How do you deal with endpoints that are down or 500'ing? What kind of retry policy or backoff occurs? Related, how do you notify clients when their endpoints are having trouble? (I ask because that's PII that I then have to share with you). 2. Is there support for message signing (e.g., HMAC) to let clients verify that the webhook really came from us? How does it work? 3. Any kind of deduplication support? One use case we had was that certain webhooks only required the latest delivery. e.g., product inventory. If we previously failed to deliver a webhook, but have a newer version pending, our next attempt should try to send the newest version. 4. Is it possible to delay hydrating data in the payload? It seems the expected usage is that I send a blob of data and you take care of the last mile and send it. Is it possible to send you an id and then you call back to my service and fetch the latest version of that object just before delivery? 5. How are webhook subscriptions actually managed? e.g., my app lets users register webhook URLs? How do I get those URLs to your service? 6. The big question: What do I do if your service is down? [1] - https://news.ycombinator.com/item?id=25992800 https://news.ycombinator.com/item?id=25992800

tasn 6y ago
Thanks for asking: 1. Exponential backoff. We don't notify clients, but we notify you with a webhook. We actually don't have it implemented yet, but will have in the next week or two. 2. Yes, and libraries for some languages (more coming) to easily verify it. See the docs for how it works, but standard stuff. We also plan on offering end-to-end encryption in the very near future so that we can't even access your payloads. 3. No, and no plans for supporting it for now. Does anyone do it? I think sending all of them is actually a feature. 4. Could you elaborate? You mean changing the webhook content in each attempt? No plan at the moment. Similar to the previous point. We consider webhook payloads as immutable messages. 5. You can either use our API to add them, or redirect users to a management UI we built with a one-time password. We will also offer JS libraries to make it easy to build your own UI. 6. I answered it a few times in this thread. Here's my original sloppy comment (with a link to a comment with more context): https://news.ycombinator.com/item?id=26400510 https://news.ycombinator.com/item?id=26400510

dgudkov 6y ago

@tasn, do you have a client library? PS. On a side note, it would be very nice to have a standard for webhooks similarly to OAuth. We're designing a solution for accepting various webhooks and the variety of negotiation schemes required by various cloud services is absolutely counter-productive.

tasn 6y ago
Yeah we do. Only for Python and JS (TypeScript) at the moment, but we will add more. Both for the sending part (it's really just a REST API under the hood for now), and the consuming (verifying signatures).

ianstormtaylor 6y ago

Extremely good idea. I've had to implement webhooks in the past and it was a huge pain (and my implementation likely had tons of bugs anyways). Turning into a well architected service seems like a perfect fit. Congrats on the launch and good luck!

tasn 6y ago
Thanks a lot!

owaislone 6y ago

This looks nice but don't I still have to invest all the engineering to make sure my calls reach Diahook service in the first place? The argument from diahook seems to be "we'll never go down". That's covered by SLAs by all companies that Diahook would be forwarding my calls to. Does Diahook claim 100% uptime? That's impossible. Even if it were possible, there are many other points of failure between my service and Diahook and I need to take all of them into account. Once I do that, I don't see much point in using Diahook. This would've been better off as a library I think. There are other features/reason that would make me use a "webhook service" and I've contemplated building one before but mainly for async message passing between systems. Anything sync and you almost always need to take care of all the failure states. This could be useful as a library or side-car. I can't help but think of this as a plugin for something like Envoy even though Envoy probably does a lot of this already.

tasn 6y ago
Hey, thanks for the feedback! We don't claim 100% SLA, as you said, it's impossible. I already replied to this a few times in this thread. I think the same can be said on every other API company, including Stripe, Sendgrid, Twilio and etc. If this is a concern for you, you need to take care of that, if it's not a concern for you, then Diahook is not any different. Anyhow, we take of other things other than just deliverability. We sign the webhooks for you to prevent SSRF, we implemented a retry logic, we have monitoring on all of these, and all of the other things I mentioned elsewhere. I mentioned it elsewhere in this thread, I don't see how this can be a library. It's a standalone service that needs to be run and monitored, needs to scale with your usage, and you need to make sure it doesn't hang, the queue doesn't get too long, and etc. I actually say it in the post, webhooks aren't as simple as they seem.
- vgel 6y ago
  It seems to me that people saying your service is also potentially unreliable are missing the point a bit. By paying you money, there's a customer relationship, an SLA, etc. As a (hypothetical) SAAS company, I don't get an SLA from my customers that their webhook consumer endpoints won't go down, but I do get an SLA from Diahook.

GhvstCode 6y ago

Hey, This is an amazing product! Congratulations on the launch. At Hookdeck(hookdeck.io), we are solving a similar problem. Hookdeck sits between the API provider & your service, ensuring you never miss a webhook notification. We provide the queues for reliable webhook ingestion and the tooling for easy monitoring and troubleshooting, Automatic & manual retries, event filtering. You should check us out

tasn 6y ago
Thanks a lot! And yeah, I'm familiar with hookdeck, your co-founder already commented in this thread. :)

deleted 6y ago

[deleted]

kondro 6y ago

Does this have any relationship with https://www.etesync.com/ https://www.etesync.com/ and https://www.etebase.com/ https://www.etebase.com/ ?

tasn 6y ago
Same creator (me), but otherwise no. :)

xrd 6y ago

The page says backed by YC, right? Are you from a YC batch?

tasn 6y ago
Yeah, YC W21!

edoceo 6y ago

Will this make it easier to share from my phone to my own we hook service?

tasn 6y ago
Not sure I follow. Could you please elaborate?

runako 6y ago

This is cool! One problem I've run into with Webhooks in the past is not being able to audit every call after the fact. I want to be able to see which endpoints were called, when, with what payloads (logs scrubbed of PII etc.). This information is invaluable in responding to support queries. Good luck!

tasn 6y ago
We have the ability to audit and inspect past calls. We don't yet scrub PII, though we have a few features down the pipeline that will enable just that. Thanks for your comment!

rozenmd 6y ago

This looks awesome - I'm in the middle of building https://onlineornot.com https://onlineornot.com and was just about to put the webhook functionality on hold for a bit before seeing this

tasn 6y ago
Hehe, I know this story too well, I've been there before! Feel free to reach out (email: tom @ the domain) if you have any questions or need any help! Oh, and please share feedback.

ezekg 6y ago

This is very cool. I scratched down "webhooks-as-a-service" into my "business ideas" note years ago after building my own webhook system for keygen.sh (mine is backed by Redis+Sidekiq). Lots of edge cases over the years. Glad somebody is running with the idea!

tasn 6y ago
Thank you. :)