The reality of &#x27;web hooks&#x27; in a really well written API is something that still cannot be relied on.<p>I use an API for a shipping company that fulfils orders for USA&#x2F;Canada. It does have &#x27;web hooks&#x27; to update orders with tracking numbers and status updates. It also has some type of regular update to make sure that any orders left &#x27;open&#x27; are updated even if they should have been updated already.<p>It all works, but only 99% of the time... There are many orders left &#x27;open&#x27; 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.<p>So, despite the wonders of the &#x27;web hooks&#x27; 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.<p>The &#x27;web hooks&#x27; 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 &#x27;web hooks&#x27; 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.