Thanks for getting in touch!
Sounds like you'd want to check the Fulfillment Order Resource.The 'on hold' status would be present on GETS to the the Fulfillment Order Resource (docs). FulfillmentOrders in API version > 2021-07 can have a status of ON_HOLD.
Status is not actually a property on the Order you'll note here - the omission of order status on the object is that way by design presently. Status is used for example as a filter on the endpoint. Hope that helps!
Hi - I'm running into problems here as well. The "Hold fulfillment" in the Admin UI, and apps using Order Fulfillment API that place Hold, don't reflect in the JSON order object "fulfillment_status" payload. They stay 'null.' I see you say it's just a filter, but if you request an order that is "fulfilled" or "partial," you can see that fulfillment_status in the payload.
We have an ERP partner who has built their integration using "fulfillment_status." Our holds are not being applied.
I see that GraphQL has 'displayFulfillmentStatus' on the Order endpoint, and it does update with the Admin. But it's confusing that there's no differentiation in "fulfillment_status" in JSON for an order between Unfulfilled and On Hold, especially when there is if it's Fulfilled.
To clarify, in REST, fulfillment_holds are not a property on the order. As we know, they are only property on the fulfillment order in REST presently which can be queried to get the on_hold status (docs).
I concur how it could be confusing in terms of the lack of parity between the REST and GraphQL endpoints however and what is returned in the fulfillment_status (on the order) in REST (when compared with displayFulfillmentStatus in GraphQL, which will return the on_hold value as we see in Dave's screenshot above.
Not to add layers of complexity here, but we have example documentation for building fulfillments for two cases - firstly as an Order Management app(docs) and secondly, as a Fulfillment Service app(docs) - there's REST/GQL examples in both. The distinction between the two is made here.
Lastly, Using the Fulfillment and Order resources separately is considered legacy behaviour - please feel free to check out the documentation here regarding some benefits of FulfillmentOrders here. Hope this explains some more!
Call it property or filter, but practically speaking, "admin/orders/SOMEIDHERE.json" has for a long time returned "null," "partial," or "fulfilled." Those mapped to possible order statuses of "unfulfilled," "partially fulfilled," and "fulfilled." Now there's a new status (or at least much more prominent), "On hold," and it maps to "null" just like unfulfilled. So it's breaking existing implementations. And to fix would require querying multiple endpoints, which means actually paying a developer for non-trivial amounts of time.
You don't have to sell me on FulfillmentsOrders, I use it myself. But we have legacy integrations, and I get that it's "legacy behavior," but updates shouldn't break legacy apps! Especially this quickly. I don't think FulfillmentOrders is that old.
You've got "fulfillment_status" on REST orders endpoint, now there's a new status, can you pls add it?
Thanks for the feedback and certainly, I've made this known to our Product teams internally today as any decisions concerning the structure of our platform, API's and updates are handled by that team. I cannot provide a timeframe for any API update (any update would be communicated here in the Shopify Community Forums and on our Developer Changelog), but I can confirm that I've made our partner's voices heard regarding the above points this morning. Thanks.