I'm Arturs and i'm full stack web / app developer with more then 10 years experience.
I have been working in various fields, starting from cryptocurrency, finances and ending with human resources.
I do not trust anything, even my own code. The point of webhooks is to allow immediate notifications between different parties. That's a requirement of nowadays where everything should happened very fast, almost instantly. Sending some regular request to the 3rd party from your application should be as a fallback solution, to make sure that the data is in sync in case something went wrong with the webhooks. Though, in 99.9% of cases it all we be fine with webhooks.
Error handling depends very much on the implementation (on both sides). HTTP allows for very robust error-handling, and a web-hook can choose to try again or send a notification to an administrator when message delivery fails, and the callee can communicate what went wrong and whether the caller should try again.
I personally don't trust web hook callbacks..
If they check that response was successful then sure..
But i have been always afraid that if webhook callback is sent and application triggers error and data is not synchronized.. what next?
I would better build it in on my application side to send request to third party application to get data.. not wait for callback from them..
I do not trust anything, even my own code. The point of webhooks is to allow immediate notifications between different parties. That's a requirement of nowadays where everything should happened very fast, almost instantly. Sending some regular request to the 3rd party from your application should be as a fallback solution, to make sure that the data is in sync in case something went wrong with the webhooks. Though, in 99.9% of cases it all we be fine with webhooks.
Stripe is the perfect example for making sure your webhooks are secure and filled with contingencies (helping you test error handling).
Error handling depends very much on the implementation (on both sides). HTTP allows for very robust error-handling, and a web-hook can choose to try again or send a notification to an administrator when message delivery fails, and the callee can communicate what went wrong and whether the caller should try again.
Nice insight. I think both should be available. There is a case to be made for both depending on the data/task.