Shopify Events api - doesn't return order timeline events

I am trying to get all order events for a shop for my shopify app. What would be the best scalable way?

I have tried Events API, the documentation for Events API says to use :

GET /admin/events.json

to retrieve a list of all events for a shop

This is the official list in the API documentation https://help.shopify.com/en/api/reference/events/event#orders

authorization_failure
authorization_pending
authorization_success
cancelled
capture_failure
capture_pending
capture_success
closed
confirmed
fulfillment_cancelled
fulfillment_pending
fulfillment_success
mail_sent
placed
re_opened
refund_failure
refund_pending
refund_success
restock_line_items
sale_failure
sale_pending
sale_success
update
void_failure
void_pending
void_success

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?

4 Likes

+1

Same issue here, please help

+1. Any ideas?

I have the exact same need.

User Case

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?

Cheers, Umar

1 Like

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.

1 Like

Did anyone ever get this working? I found the same issue after following the ironic docs message about not relying on updated_since.

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.

Thanks, I wrote it with updated_at but found it too chatty. I may inspect the event for the updated ones to see if they really updated.