The reality of 'web hooks' in a really well written API is something that still cannot be relied on. I use an API for a shipping company that fulfils orders fo

The reality of 'web hooks' in a really well written API is something that still cannot be relied on. I use an API for a shipping company that fulfils orders for USA/Canada. It does have 'web hooks' to update orders with tracking numbers and status updates. It also has some type of regular update to make sure that any orders left 'open' are updated even if they should have been updated already. It all works, but only 99% of the time... There are many orders left 'open' with the only option being to look up the orders and assess them manually. This is a big task even with only 1% or so to follow up and double check. So, despite the wonders of the 'web hooks' approach, we are going back to API polling, to get all order updates since [last poll time] and updating order statuses accordingly. We will disable the web hooks once the straight API + polling approach is fully tested. A client library for the API will also have to be built so that simple getters and setters can be used for updating order statuses and inventory levels. The 'web hooks' approach ultimately does not work reliably enough for us, so a more thorough and robust solution is needed. Really it would have been better to have not gone the 'web hooks' way at all, it would have spared us the problems we have had with only 99% of the information coming through. Nowadays customers are quick to talk online about poor service so this type of thing is of consequence.