Inconsistent behavior with Add to Cart limit when a discount code is applied (422 vs 200 response)

I’m encountering an inconsistent behavior related to the Add to Cart limit when updating product quantities in the cart. When I add or adjust the quantity of a product and the requested quantity exceeds the Add to Cart limit, the request normally returns a 422 error and the response displays a message like “Only X items were added to your cart.” This behavior is expected and works correctly when no discount code is applied.

However, when a discount code is applied, the behavior changes. Even if the requested quantity exceeds the Add to Cart limit, the cart still ends up with the maximum allowed quantity, which means the limit is respected, but the server response returns a 200 status instead of a 422 error. As a result, no error is caught on the frontend.

So to summarize, without a discount code, exceeding the Add to Cart limit returns a 422 error as expected, but with a discount code applied, exceeding the limit returns a 200 status even though the quantity is capped correctly.

Hi @Ilan_Zerdoun - thanks for waiting while we looked into this!

I tried reproducing on a test store with an add-to-cart limit of 50 items. When I exceeded the limit via the Cart AJAX API (/cart/change.js), I consistently got a 422 response both with and without a discount code applied. The quantity was capped correctly in both cases and the error message displayed as expected.

For the Storefront GraphQL API, mutations like cartLinesUpdate return a 200 status with a warnings array containing a MERCHANDISE_NOT_ENOUGH_STOCK code when the quantity is adjusted. This is by design - cart warnings indicate the mutation succeeded but automatic changes were made.

Could you share a bit more detail on your setup? Specifically:

  1. Which API are you using - the Cart AJAX API (/cart/add.js, /cart/change.js) or the Storefront GraphQL API?

  2. What type of discount is applied (automatic vs code, percentage vs fixed amount)?

  3. Can you capture a request ID from the response headers when you see the 200 instead of 422?

The above info will allow me to look into this further for you!