Updated Deadline: Aug 1st -- [Deprecation] Important changes to ProductVariant, Refund and Fulfillment APIs

[Ryan]

UPDATE JAN 2: 

https://ecommerce.shopify.com/c/api-announcements/t/deadline-reminder-important-changes-to-productva...

UPDATE SEP 14 

Hey Devs!

We've recently shipped a new change to help with identifying calls that we consider deprecated.  We've added a new header to return on these calls:

X-Shopify-API-Deprecated-Reason

If you receive one of these headers in your response, this means Shopify considers that a deprecated call.  This is an effort to allow these calls to be machine readable, and loggable, in order to assist developers in identifying the areas that need to be updated.

Examples of calls that will return this header:

• Creating a fulfillment without a location
• Creating a product with variants that have "inventory_quantity"
• Creating a new variant on a product that has "inventory_quantity"
• Updating a variant with "inventory_quantity_adjustment"
• Updating a variant with "inventory_quantity"

Happy Coding!

UPDATE JUNE 28: 

Hey Devs,

Just want to let you know that we are extending the deprecation deadline from July 1st to August 1st.  There will be a new post tomorrow with more details, but we just wanted to get it out there to maybe relieve some of the stress you are feeling headed into the weekend.

Most, if not all of your questions will be answered in the post tomorrow so try to save any queries for that!

Cheers All!

Ryan

Hey Devs,

Shopify is preparing to release multi-location inventory features to all merchants this summer. All apps that create fulfillments or manage inventory will need to be updated by July 1st, 2018, to remain functional on shops that track inventory across multiple locations.

Key dates

July 1st, 2018

• Apps will no longer be able to create fulfillments without specifying a location
• Apps will no longer be able to set inventory on the Product/Variant APIs

Migrating to support multi-location fulfillments

Shopify fulfillments are currently “location unaware”, meaning that when an app creates a fulfillment and fulfills an order, Shopify decrements the inventory with no concept of which location that inventory should be decremented from. In order to support merchants with inventory allocated across multiple locations, apps will need to include a location_id when creating fulfillments.

For details on how to migrate your apps to support multi-location, see our Multi-Location Fulfillment Migration Guide.

Migrating to support multi-location inventory

Currently inventory is set and adjusted on the product variant and is not tracked by any particular location. In anticipation of multi-location inventory, Shopify has released a new Inventory API, which includes two new endpoints: Inventory Item and Inventory Level. The Inventory API will allows apps to effectively manage inventory quantities across multiple locations.

For details on how to migrate your apps to support multi-location inventory, see our Multi-Location Inventory Migration Guide.

We’ll keep you up to date as we continue to make improvements to our platform’s multi-location fulfillment and inventory management capabilities, so you can continue to build the best apps to help extend these new features.

If you have any questions about this change, please read our detailed FAQ or contact deprecations@shopify.com.

Thanks,

Shopify Apps Team

[Conner]

Ryan,

Thank you for the response.

Will inventory_quantity remain as a field within Variants-- just as read-only? Or should I expect to get all inventory information from the Inventory API going forward?

Thanks!

[Ryan]

Yes inventory_quantity will remain on product variant as a read-only property.  It will reflect the sum of inventory available at all locations.

[Tahar_from_Stoc]

Hi Ryan,

We have finished our move to the new inventory APIs.

We followed the documented upgrade checklist published on the Multi location API page and while the changes worked for most of our customers, these badly failing (HTTP 422) for a few other ones (they are super upset at us right now 🙂 )

We have emailed the details of the failure to Shopify support, ticket ID: 9347019

Would you be able to help us on this please?

Thank you in advance,

[Ryan]

Tahar,

Took a quick look, the inventory item you are trying to update is assigned to a fulfillment service for managing it's inventory.  When an item is set to use a fulfillment service, only that FS can update the inventory.

[Tahar_from_Stoc]

Hi Ryan,

This is a major breaking change - we have many customers relying on us to update their inventory whome we will no longer be able to support 😞

It is said in the documentation that setting inventory for an item managed by a fulfillement service should work fine as long as Shopify is instructed to disconnect if necessary. 

Again, this is major breaking change for us from a finantial perspective as we need to let go of all customers relying on fulfillment services. It is also a major breaking change for our customers as they need to find other ways of managing their inventory before July 1st.

Can you please double check this and get back to us so we can plan accordingly?  

[Ryan]

I'm not really sure what actions you are trying to do here, is this a fulfillment service you have created and you are trying to manage the inventory?  Or is this a pre-existing fulfillment service that you do not manage?

EDIT: You are also including both relocate_if_necessary and disconnect_if_necessary in your call, these properties are for different endpoints, depending on what you are trying to do, one of these is incorrect.

[Tahar_from_Stoc]

We are an inventory management app (we are not a fulfillement service) - most of our customers own two to six stores all using the same inventory. Our app keeps the inventory of all stores in sync at all times. The issue reported above is from one of our customers for whome we are failing to keep his stores in sync as we get 422 errors whenever we try to update the stock levels. 

EDIT: You are also including both relocate_if_necessary and disconnect_if_necessary in your call, these properties are for different endpoints, depending on what you are trying to do, one of these is incorrect.

We are trying to set the available inventory at a given location, which flag should we use? 

[Ryan]

See above edit, if you are just setting inventory with POST /admin/inventory_levels/set.json then you shouldn't include relocate_if_necessary as that is only for POST /admin/inventory_levels/connect.json as per the documentation.

[Tahar_from_Stoc]

See above edit, if you are just setting inventory with POST /admin/inventory_levels/set.json then you shouldn't include relocate_if_necessary as that is only for POST /admin/inventory_levels/connect.json as per the documentation.

We tried this and we are still getting 422 errors. Probably because the stock level at that location can only be changed by the fulfillement service it is tied to? 

[Ryan]

You also need to specify the location of the fulfillment service as the location_id.  If you can't get that to work, send a copy of your X-Request-Id header in with the ticket and I'll make sure it's looked at.  

[Tahar_from_Stoc]

Hi Ryan,

Sorry for the late reply. 

You also need to specify the location of the fulfillment service as the location_id.

Yes, we do send the location ID as part of the inventory level payload. 
An important point I forgot to mention is that this works just fine for other stores with fulfillement services attached so we can definitely update stock level of product variants attached to third party fulfillement services. It is just the one (and few other stores from other customers) reported in the ticket which is failing for obscure reasons. 

[Ryan]

Thanks Tahar, this seems like it would be best continued through your support ticket.  It's been escalated to technical support who can look into the specifics of the store and why it may not be working.  As much information as you can add to the ticket will help them greatly.

Cheers!

[JAS_Technology]

Hi again. I'm just looking for a confirmation on something. We will still be able to create a variant with a SKU correct? Updating it requires the inventory_item endpoint but we can create a product_variant with a SKU populated in one call still?

[Ryan]

Current implementation allows the creation or editing of SKU on both the product variant AND the inventory item.  Upon updating either of them, shopify will update the other to match, so they will be in sync.

[JAS_Technology]

By "current implementation" you mean right now, however on July 1st this will no longer be the case? The docs here say:

• Updating SKU will only be available using the Inventory Item endpoint.

[Loren_D1]

Will there be a 'count' endpoint for the inventory_levels?  The GET /admin/inventory_levels.json has 'page' and 'limit' properties, but they aren't very useful if I don't know the 'count' of items.

[Ryan]

By "current implementation" you mean right now, however on July 1st this will no longer be the case? The docs here say:

• Updating SKU will only be available using the Inventory Item endpoint.

We haven't yet removed the ability to set SKU on product creation using the REST API.  And this is not planned to be removed on July 1st, but I wouldn't consider it a permanent solution.

You could however, set SKU on product creation using the GraphQL Admin API (and update it's inventory in the same call), quick example below, working on a more detailed post about it;

 

mutation {
  productCreate(input: {title: "Test Product", variants: [
    {
      inventoryQuantities: 
      [
        {locationId: "gid://shopify/Location/13968900152", availableQuantity: 5},
        {locationId: "gid://shopify/Location/13969457208", availableQuantity: 10}
      ],
      inventoryManagement: SHOPIFY,
      sku: "TestSKU"
    }
  ]})
  {
  product{
    id
    variants(first:10) {
      edges{
        node{
          id
          sku
          inventoryItem{
            id
            inventoryLevels(first:10){
              edges {
                node
                {
                  id
                  available
                  location{
                    name
                    id
                  }
                }
              }
            }
          }
        }
      }
    }
  }
	userErrors {
      field
      message
  }
  }
}

[JAS_Technology]

How about **updating** SKU using Rest API on the product_variant endpoint? Will that be supported after July 1st?

[Ryan]

Will there be a 'count' endpoint for the inventory_levels?  The GET /admin/inventory_levels.json has 'page' and 'limit' properties, but they aren't very useful if I don't know the 'count' of items.

There are no plans for a count endpoint

How about **updating** SKU using Rest API on the product_variant endpoint? Will that be supported after July 1st?

Writing the sku field whether it is updating or initially setting it, will not be removed on July 1st.  You can however consider it deprecated, as we've released the "new and better" way to handle it.

[JAS_Technology]

Ok thanks. Ryan, I really appreciate all the answers/guidance here. I think I can speak for all developers when I say this change is really rough and we are just trying to get our apps into a state where they won't break. We can then work on optimizing them further to use latest/greatest techniques to make them as efficient as possible.