standardizedProductType ignored in productCreate and productUpdate

[JohanCL]

I'm trying to create and update products with the new standard product types, using the GraphQL APIs. The standardizedProductType parameter is verified and accepted, but the product type is not actually set or updated on the products. I just tried with this mutation query in the Shopify GraphiQL App:

mutation {
  productUpdate(
    input: {
      id:"gid://shopify/Product/6749070262332"
      standardizedProductType:{
        productTaxonomyNodeId: "gid://shopify/ProductTaxonomyNode/888"
      }
      title: "Updating the title too"
    }
  ) {
    product {
      standardizedProductType {
        productTaxonomyNode {
          fullName
          id
        }
      }
      title
    }
  }
}

The title of the product is indeed updated, but the standard product type stays the same as it was before, be it unassigned for a new product or whatever I set it to manually in the admin interface.

Has anyone had any luck using this new API? I'm using the latest stable API version (2022-01), but the pre-release versions also don't work for me.

[Matthew10]

same issue here

[alessmar]

I have the same issue, I tried API version 2022-01, 2022-4 and unstable and both productCreate or productUpdate mutations ignore standardizedProductType, below an example:

mutation {
	productCreate(
		input: {
			title: "Foo bar"
			vendor: "Acme"
			standardizedProductType: {
				productTaxonomyNodeId: "gid://shopify/ProductTaxonomyNode/301"
			}
		}
	) {
		product {
			id
			title
			standardizedProductType {
				productTaxonomyNode {
					id
				}
			}
		}
		userErrors {
			field
			message
		}
	}
}

I get:

{
	"data": {
		"productCreate": {
			"product": {
				"id": "gid:\/\/shopify\/Product\/7233567457441",
				"title": "Foo bar",
				"standardizedProductType": null
			},
			"userErrors": []
		}
	},
	"extensions": {
		"cost": {
			"requestedQueryCost": 12,
			"actualQueryCost": 11,
			"throttleStatus": {
				"maximumAvailable": 1000.0,
				"currentlyAvailable": 989,
				"restoreRate": 50.0
			}
		}
	}
}

[csam · Accepted solution]

Hi @JohanCL and all - 

Thanks for reaching out about this. Our developers were able to put out a fix for this today, and the field should now be working as expected. 

Regards,