Getting deprecated call header with simple order creation

[wriffle]

I am trying to track down the source of a deprecated call warning that recently appeared in my main store's admin when using the admin REST API. To narrow it down, I have begun aggressively tracking the returned headers and looking for the "X-Shopify-API-Deprecated-Reason" header. While there may be other instances I haven't eliminated, so far I have narrowed the source of this down to when I create an order in Shopify that originated outside of Shopify. I don't see that I am calling anything in the order resource that is deprecated.

I suspect there is a bug here. In my test store (and in my live store as well) I get the "X-Shopify-API-Deprecated-Reason: https://shopify.dev/changelog/property-deprecations-in-the-admin-api-order-and-lineitem-resource" header when creating a simple order with this JSON: {"order":"customer":"id":CUSTOMER_ID_REDACTED},"line_items":[{"variant_id":VARIANT_ID_REDACTED,"quantity":1}]}} (yes, I use existing customer and variant IDs form the relevant store). The order gets successfully placed, but the warning header is returned. I don't know if I can make it more clean and simple than this. This, in turn, makes me think that perhaps there is a bug.

In my tests, I have POSTed this to the 2022-04, thru 2023-04 REST APIs (e.g., https://mysite.myshopify.com/admin/api/2023-04/orders.json) and I get the same result.

Does anyone else see this? Is there something I am doing incorrectly? Could this be a bug?

[magecomp]

Hello @wriffle 

To avoid this warning, you can update your request to use the "customer_id" property instead. The following is an example of a valid order creation request that does not generate a warning:

{
  "order": {
    "customer_id": CUSTOMER_ID_REDACTED,
    "line_items": [
      {
        "variant_id": VARIANT_ID_REDACTED,
        "quantity": 1
      }
    ]
  }
}

 The shopify team is aware of it, and they must be working on a fix. In the meantime, you can avoid the warning by using the "customer_id" property instead of the "customer" property.

[wriffle]

@magecomp  Thank you for taking the time to reply - I truly appreciate it very much.

You are correct that using "customer_id": CUSTOMER_ID_REDACTED does not throw a deprecated warning header. However, it also does not set the customer. My best guess is that the REST API engine just ignores a property it doesn't understand.

In further testing, I have realized that if you set line_item array's objects properties other than variant_id and price, it seems to also throw the deprecated warning header. This is true even when setting the quantity property (although it should be noted that it will properly set the quantity, just like using the "customer":{"id":CUSTOMER_ID_REDACTED} will correctly set the customer):

{

"line_items":[

{

"variant_id":VARIANT_ID_REDACTED,

"price":25,

"quantity":1

}

]

}

I have not gone exhaustively through all of the potential order object's properties, but I have tested various line_item properties (e.g., "fulfillment_status": "fulfilled") and all of them I tried outside of variant_id and price cause the deprecated header to be thrown. I even tried it with just the line_item variant_id and quantity like in your example and it threw the deprecated warning header.

Needless to say, getting a deprecated warning when doing simple tasks like creating an order that sets a customer and sets a line item's quantity to any specific number can't be correct (and it is in contradiction to the API's documentation).

[magecomp]

In the meantime, you can avoid the deprecated warning by not setting any properties on the line_item object other than variant_id and price.

Here is an example of a valid request to create an order that sets a customer and sets a line item's quantity to 1:

{
  "customer_id": CUSTOMER_ID_REDACTED,
  "line_items": [
    {
      "variant_id": VARIANT_ID_REDACTED,
      "quantity": 1
    }
  ]
}

This request will create an order with the specified customer and line item. It will not throw a deprecated warning.

[wriffle]

Sorry, but I beg to differ. I am not sure which version of the API you are testing it against, but

{
  "customer_id": CUSTOMER_ID_REDACTED,
  "line_items": [
    {
      "variant_id": VARIANT_ID_REDACTED,
      "quantity": 1
    }
  ]
}

which sets the quantity, will throw the deprecated header flag when tested against the 2023-04 API. It also does not set the customer.

However, it is true that if your JSON is this:

{
  "customer_id": CUSTOMER_ID_REDACTED,
  "line_items": [
    {
      "variant_id": VARIANT_ID_REDACTED,
      "price": 15
    }
  ]
}

Then it will not throw the Deprecated warning header. It still does not set the customer.

So, while it is possible to create an order that does not throw the deprecated warning header, the way you have to finagle it is, at least for my real-world purposes, useless. I need to set the customer and I need to be able to set line_item quantities (amongst other order properties).

This needs fixing.

[ShopifyDevSup]

Hi @wriffle,

Thanks for your post. The return value from creating an order with the REST Admin API orders.json endpoint still includes the LineItem.fulfillment_service value in all versions so that part of the deprecation warning on the linked changelog is still valid. 

When testing today we weren't able to replicate not getting that changelog warning when creating an order with different payloads, it came through all the time which is expected.

With a REST API It's not possible to tell what part of the return value is going to be used so everyone gets that particular warning for now, and there isn't currently a posted date we can share as to when that deprecation warning will expire.

A benefit of the GraphQL Admin API in situations like these is that it allows specifying what values are required in the return, particularly with the Orders object where there's a lot of data returned that might not all be required.

Hope you have a great day,
Jon551

[wriffle]

Thanks @ShopifyDevSup (Jon551) for the response.

Did you try providing just a payload of a lineitem with only the variant_id and price properties set? That didn't trigger the deprecated warning (or at least it didn't last week when I was testing this more thoroughly). So, not sure I accept the claim that it is happening on all payloads all the time, but that's not really the point.

It doesn't really bother me if it returns a deprecated warning header so long as that doesn't turn into a warning in the shop's web admin that some calls are deprecated and may stop working. Not that it matters, nor that it will sway y'all one way or another, but I am not sure if I agree or not on Shopify setting that header when their return JSON object contains deprecated information. It seems that it would be more valuable to developers to only set that header when we call a function supplying an object with the specific deprecated properties. I mean, if our calls are good, and we have no control whatsoever over the object returned by the REST API, it seems silly to set that flag. As I can attest, setting that header can lead a developer into a bit of a black hole when trying to track down any deprecated calls.

And, yes, I realize I could move over to GraphQL. Considering I have a relatively large code set built around the REST API (much of which predates the advent of GraphQL), moving to GraphQL means adopting a whole new paradigm. Not something to be undertaken lightly although I suppose I could cherry-pick specific spots.