I'm really interested in utilising Shopify's webhook filtering feature—specifically the ability to apply filters like orders_fulfillment_status when setting up a listener like orders/updated.
My use case is that I want to look for shipping address changes and pass them to the order in NetSuite (subject to status etc)
My understanding currently is that, when using a listener such as orders/updated, Celigo receives all update events, regardless of whether the changes are relevant (e.g., a shipping address change) or not (ag any fulfilment event triggers the flow currently). This creates unnecessary noise and we have to implement additional filter logic inside the flow.
Shopify now allows developers to filter webhook triggers at the source by attributes like orders_fulfillment_status, so that only updates matching certain criteria (e.g., unfulfilled or partially fulfilled orders) are even sent to the webhook endpoint.
It would be great if Celigo could add this functionality to reduce the amount of calls we need to make?
Shopify only supports webhook filtering via API — there’s no UI option to apply filters when creating a webhook. You can update the webhook with filters using a tool like Postman, but honestly, it’s probably better to filter the data in your Celigo flow instead.
Filtering in the flow is easier, more transparent to other users, and avoids confusion since Shopify’s webhook filters aren’t visible in their UI and can easily be missed.
So really, the choice is:
- Filter what Shopify sends (harder to manage, not visible)
- Or filter in the flow (easier, visible in Celigo)
I’d go with the flow output filter — it’s simpler and maintainable.
Also, the Shopify webhook filter doesn't seem to give any additional functionality. As in, there is no flag to say that the order/update event was due to address change.
That is true but I could have filtered out all the noise for order updates that are simply because an order has been fulfilled.
I guess at the end of the day I am trying to get my flow as efficient as possible. Every order gets updated at some point in Shopify - but only a small % get address changes.
I have currently got an output filter on the listener (to exclude closed orders) and then also using branching to further reduce processing. It currently looks like:
Step 2 looks for order comments that include "updated the shipping address for this order" adding a results mapping "PROCEED" - which is used conditionally at the branching to step 3 (updates the address in NS) - and finally step 4 adds a further tag to the order in Shopify (Address_Updated_NS) - which in turn is then used as an output filter in step 1 (to prevent the same address change being updated each time the order is edited in Shopify).
I think this works. I would be open to any ideas how further to improve this. My concern is that for every order that is updated in Shopify - they ALL go through this flow and each step runs, albeit with no data. You will see in the image that the flow took 20 seconds to run on an order that was updated but was filtered out at the first stage.
Is this OK? To have a flow that will be triggering and running so much? If we are processing 1000s of orders a day is that still ok? Should I be concerned about API call limits, concurrency, execution time....?
If most records are filtered out by the webhook output filter, then I wouldn't be concerned about performance here. If you are having to hit the lookup step often, then I would potentially be concerned, but I'm not sure if there is another option. In the payload that Shopify sends for it's webhook, does it not include the comment data? It would be nice if the webhook just passed it because then you wouldn't need a lookup at all.
Thanks again @tylerlamparter
Sadly the order/updated payload doesn't include comments - they are only available using graphQL. It does however include tags so one other option is to get the user to add a tag to indicate a sync is required and use that as part of the output filter without the need for a lookup step. The downside to that is it is reliant on users remembering to add the tag... whereas the comments are system generated so will always be there... sings and roundabouts 
I appreciate the input you have given to all of my questions!
1 Like
