We have several clients who use 3rd party “bundling” apps and other services that create certain product variants as non-physical items (requiresShipping: false). Historically we’ve advised clients to not assign these non-shipped variants to our Fulfillment Service location, but of course many of them have done it anyway so we’ve built in handling for these cases over the years.
Suddenly, seemingly overnight, our clients lost the ability to assign these items to our location (pre-existing items assigned to our location have remained untouched), and the verbiage in the error message makes it sound like there’s now some setting we need to adjust on our Fulfillment Service. Can anyone advise on what has changed and what we need to adjust as a result?
@Liam-Shopify Anyone have any guidance on this? Seems a change was put in place by Shopify without any warning, and now we have a lot of shops reaching out to us about this because they were given no time to alter their workflows.
Since this is getting no attention here I had to spend the day digging in on my own. It looks like Shopify has added the requiresShippingMethod field to the Fulfillment Service object in GQL version 2025-04 and defaulted it to true for everyone, even though we’re not yet on 2025-04.
Gee thanks, Shopify. Maybe warn us about breaking changes, or at least port that new field back to the older supported API versions so we can do something about it. Also, maybe don’t push everyone to the GQL API if it’s not actually ready for action (requires_shipping_method is present in older versions of the REST API).
Hey @ktbishop, I apologize for the silence here. I’m getting caught up on this now.
When you created your fulfillment service, are you using REST or are you using Graphql with a pre 2025-04 version?
Does updating your fulfillment service to False resolve this for you?
I did find the changelog here, but you’re right in it doesn’t give guidance or warning to developers that may have not set this previously. I’ll dig in to see if this is expected or not. Thanks for reporting it.
Thanks for pointing out that changelog entry. It looks like we didn’t scroll quite far enough so we missed it.
Setting it to false does resolve things for us, so we have that as a workaround on a case-by-case basis until we finish our GQL migration.
