but it doesn’t return all order events, only order confirmed event is returned.
The way I can see all events associated with an order is by using :
GET /admin/orders/#{order_id}/events.json,
but this solution might not work for my use case. With this endpoint, i will need to get list of all orders first and then iterate over those order IDs to get events for those orders. It’s won’t be scalable for me at order ID level, it would perfect if i can get all order events though one endpoint at the events level.
Does anyone know the best way to solve this issue?
I have been writing an integration from shopify into our backend for now primarily to update our backend with all the orders received on Shopify and updating the status as it changes on shopify. Started off using webhooks. Worked well upto a point until I started to find that there are some instances where the webhook does not fire. Also, while webhook can be a JIT update, I do need a query back mechanism to manage scenarios where the server was down, maintenance etc.
If there is a way to query all webhook events and its payload in the sequence of its occurance, that is an ideal scenario to ensure a fool proof implementation of the integration. Is there any?
I have the same problem, which is all the more bewildering because the documentation itself recommends using webhooks and events in lieu of the order updated field, and as @umarakhter mentioned, it is insufficient to rely on webhooks alone.
I looked in GraphQL as well, but there is no events connection at the queryRoot.
If updated_at turns out not to be updated in every scenario (such as in response to downstream object changes), I could have a very hard time doing this efficiently.
I’ve been using updated_at, which as far as I can tell is perfectly reliable, in that it always changes when any part of the order changes (line items, refunds, OrderTransactions, etc.). For my use case, it doesn’t matter if the updated_at date sometimes changes “when no visible fields of an order have been updated” as the docs warn, so I haven’t bothered to check if that has ever happened.