Hacker News new | past | comments | ask | show | jobs | submit login

It's not just your infra though. Say I'm a client sending you webhooks. My internet connection (if not in cloud infra) could be down, or my cloud provider might not have a route to your delivery endpoint due to a routing or similar outage. If those requests block, the client's app is going to hang or back up. If they don't block, they have to go somewhere (perhaps journaled with a task that can be executed on demand or on a recurring schedule).

My suggestion would be not only a library, but a local queue that can be managed with the library. Also, having some experience with working at a no code provider previously, ensure that it's trivial to query your service for what webhooks you can confirm were received by your infra and then delivered, perhaps by UUID.

Last, make sure it's dreadfully difficult to make changes to your systems where data loss could occur (messages dropped while returning 200 to counterparty systems, for example).




It's a good point, and actually some of our users already have this local queue implementation anyway because they want to send webhooks asynchronously. So it's definitely something to keep in mind. We already make it easy to query the service for what webhooks were delivered, but we also let you use the API with idempotency keys to ensure messages are not accepted twice.

I agree about all the issues you outlined though. One thing we plan on doing in terms of internet being down and cloud provider not having routes: have a lot of endpoints spread geographically in every region, and maybe in the same/nearby data centers.

Thanks again for the feedback!


For what it's worth, Stripe's Idempotent Requests are a nice way to handle this: https://stripe.com/docs/api/idempotent_requests

We just send the same requests over and over until they're successful. It's relatively simple to use.


Yeah, we also support idempotency (the event ID is used for that). I'll add it to that comment, I forgot to mention it. :P

Edit: ahh, I already mentioned it, it's buried in my comment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: