I has been getting this error "Compare at price needs to be higher than Price" whenever I try to create a product with price that is equal to compared_at_price field.
The API call was doing fine, until recently I have update the version from 2019-04 to 2020-04.
My guess is one of the version release has changed this behavior. But I couldn't seems to find it from the release notes from Shopify.
While Shopify allow the user to have price = compared_at_price from the admin interface to create a new product. I just don't understand that why through API call has a different requirement in here?
Is there anyone could give me some information in regarding this error?
We're hitting the same error returned - did you ever find a solution ?
Well the only solution I have is to enforcing the rule... but depending what the client want. If the client want:
1. keep the compare_at_price
then we just need to alert them there is an issue updating the variant due to this requirement.
2. don't really care about the compare_at_price
then we just check is the compare_at_price is bigger than the price value? if so then we can use the given compare_at_price. If not I just overwrite it to NULL (don't use zero... that won't work) and I saw many people using compare_at_price = 0 instead of setting it to null.....
Unfortunately you would need to assuming the users input the wrong value.
Hope this help.
Yea this is really throwing me off. In the Admin interface, a merchant is totally able to set the "Compare at price" to whatever they want. Then in the API we get blocked. Are we really supposed to mess with a variant's compare at price just so we can change the price?
Totally agree @ericdude4 - the Admin validation logic should match the API validation.
At least, the API validation should not be more strict here than the Admin UI allows - our Merchants are confused why they can set that in the Admin manually, but cannot import.
It frustrates them...
I just encountered this problem myself yesterday. I have collections that rely on compare-at-price = 0, which means nothing is on sale. I suppose compare < 1 might produce the same result, but it's a lot less clear.
What I personally find much more annoying is that the API will give you variant information that you can't save back to the same endpoint. This led to a particularly frustrating bug hunt with the Shopify Python Api which creates a complete variant object and then fails when attempting to save a modified version back to shopify.
I see a few possible solutions that shopify could hopefully implement:
Hello, @Fei1 !
Maris from Excelify app here.
Yes, that is right - the new Shopify API changes require the Variant Compare At Price to be higher than the Variant Price. We definitely feel your frustration and agree this is not a fair rule because the Admin allows setting any value at the Compare At Price manually, and Shopify native import too.
I have written to Shopify about this concern, and let's see what they can offer as a solution... 🤞
Can you please give some real-life cases on why do you need Price to be the same as Compare At Price; and why do you need sometimes Price to be higher than the Compare At Price?
That is - to raise the awareness in Shopify of this need, as the intended use for "Compare At Price" logically is "the higher price that other places usually sell for", and it's puzzling as to why the price should match the Compare At Price, or even be higher than that. Maybe some important use-cases were overlooked?
According to information from Shopify - it's planned to enforce those same validations in Shopify Admin and CSV import after Black Friday.
Thanks so much!
The problem is not that it is not consistent between Admin and the API
The problem is that this is not how retail works.
Retail works this way:
Products have RRP (Recommended Retail Price) or "Compare At" price - which should be the same thing.
When they land in your shop, your PRICE is equal to the RRP / Compare at.
If you (the retailer) desires to place a different price on the item, it could be a sale, or Black Week, or competitors dropped the price, or simply to get the stock out, you lower the price to get sales rolling. Hence: you lower the Price to be lower than the Compare At price.
There is absolutely no sane reason why your price should have to be different than the price that is recommended. On the contrary: This is default friggin behaviour.
What are we missing here?
I understand and agree with you from the business point of view .
I just frustrated about the inconsistency between the admin interface and the API requirement from the app developer point of view.
Because user is using the admin interface to do their works and setup the "wrong" values without knowing, especially when they are doing a bulk edit. These values will impact on the workflow from a Shopify app rely on the API call to update and managing the product.
Can this be resolved? yes we can and we just need to enforcing the rule from back-end before we make the update call and explain to the user why our app changing their values.
All this can be avoided, if Shopify admin page using the same rule from API and block user from using the wrong value.
To be honest, I am more interested to know why Shopify has a different rule in the admin page? Is there a special reason Shopify would like to allow user to set a compare at price less than the product's price?
@Maris You ask for the reasons a retailer would need to set the compare-at-price to a number lower than price? The reasons are all artificially created by Shopify, but they are important:
In many (maybe all?) shopify themes, if you have a compare at price that is anything other than 0 or Null, it is displayed. "Price 99.99, compare at price 99.99" ... this looks bad. This is the original sin and leads to all these other problems.
Mistake 2: Smart collections have no negative filter options and its impossible to filter on null (compare-at-price == Null is impossible), so retailers are in the habit of using compare-at == 0 to signify a full price item
So, now I want to make a smart collection called "Not on Sale" which is just full-priced items. Because of mistake 1, i can't say price==compare-at-price, and because of mistake number 2, I can't filter on null, so I setup my new "full price apparel" collection like: "type=apparel, compare-at-price >0" and I create a discount code for that collection and pass it to my marketing team. With the new null behavior this is now impossible and I really don't understand how they expect retailers to work around it.
In an ideal world, compare at price should always be MSRP (full price) and there should be some other mechanism to decide if it should be displayed or not, periodically setting it to 0 is a mess. But this behavior has been established and counted on, and now it sounds like it's being take away, hence people being cranky about it.
Finally, others didn't sound as concerned, but I personally think it's bad practice to allow less flexibility through the API than through the UI. As a developer it's hard to explain to a client that you can't do in bulk what they can do manually through their admin page.
Enormous thank you about your responses on this - I am sure Shopify will soon join those discussions and provide solutions to those issues and use-cases you are describing.
I have passed links from both of those forum threads to Shopify developer support.
The second thread is this one about the same issue: https://community.shopify.com/c/Shopify-APIs-SDKs/Compare-at-price-needs-to-be-higher-than-Price-API...
Most likely after BFCM, as I understand now everything revolves around that.
Letting you know that we have made a workaround in the Excelify app which now allows both - importing/exporting the new Product Status field with the new Shopify API, AND also allows setting the Variant Compare At Price such that it's not required to be higher than the Variant Price.
All your earlier imports that were setting the Compare At Price as equals or lower than the Price should work now.
There is a high probability that Shopify will move forward and will enforce that requirement in the Admin after the BFCM, but still, a slight chance that all of your feedback made them reconsider this requirement as well.
Anyway, for now - it should work as you were used to (in the Excelify app).
So sorry for this stressful period, and really hoping it's some good news, for now, to live through the sales season.
did you just switch back to the old API version? What was the technical solution?
setting the "compare_at_price" to be blank seemed to work for me: