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

[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!

[Jon_Schwartz]

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.

[Jon_Schwartz]

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
  }
  }
}

[Jon_Schwartz]

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.

[Jon_Schwartz]

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.