3 ms·

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 pol

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

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