Cart API - Error 422

We are using the Cart API

to calculate shipping rates and display them on the product page.

Recently, merchants started reporting issues with shipping rate calculation. After investigating, we noticed changes in the behavior of the API.

1. Change in prepare_shipping_rates response

The request to the endpoint:

/cart/prepare_shipping_rates.json

according to the documentation should return null (and it always did in the past).

Currently, however, the endpoint returns HTTP 202 with an empty response body.

We have already adjusted our implementation to handle an empty response, so this part has been addressed on our side.

2. Issue with async_shipping_rates

At the same time, another issue started appearing, which is being reported by merchants.

When sending a request to:

/cart/async_shipping_rates.json

we receive HTTP 422 with the following response:

{
  "error": [
    "There was a problem calculating your shipping rates. Continue to checkout to choose a shipping rate before you complete your order."
  ]
}

At this point, it is unclear to us:

  • why this error is being returned,

  • and what exactly we should change to avoid it.

According to merchant reports, everything was working correctly until recently, and the issue appeared without any changes on our side.

Example requests we are making

First:

fetch('/cart/prepare_shipping_rates.json', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: '{"shipping_address":{"country":"PL","zip":"32-600"}}'
});

Then:

const params = new URLSearchParams();
params.append('shipping_address[country]', 'PL');
params.append('shipping_address[zip]', '32-600');

fetch(`/cart/async_shipping_rates.json?${params.toString()}`, {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
});

Question

Have there been any recent changes to the Cart API that could affect:

  • address validation,

  • request ordering or timing,

  • expected request format,

  • or the way shipping rates are calculated?

We would appreciate any guidance on what we should verify or adjust in order to avoid the 422 error and restore the previously stable behavior.

1 Like

Same here with /cart/add and shopify version 3.89.0

Hey @sebastian.pisula, thanks for the detailed write-up - that reproduction code is really helpful.

This looks like the same issue I’m tracking in another thread where other developers started seeing the same 422 error from async_shipping_rates.json today, all without any code changes on their end. You’re not alone here it seems!

I’ve raised this with the Cart API team along with x-request-ids and reproduction details from the other reports. Will update both threads once I hear back.

@PeterParker The /cart/add issue might be separate - are you seeing the same 422 error with shipping rates, or something different with the add endpoint? If different, could you share the error response and an x-request-id from a failed request?

Hi @Donal-Shopify, my info here:

x-request-id: b9768f03-cae6-4718-9cde-27d0f7d627ce-1769521185
Status code: http://127.0.0.1:9999/cart/add 401 (Unauthorized)

// This error only occurs on the latest version that I updated this morning

Hey @sebastian.pisula , quick update - the team identified a change that was causing the 422 errors and rolled it back. The prepare_shipping_rates → async_shipping_rates flow should be working again now.

Can you confirm things are back to normal on your end?

@PeterParker The 401 you’re seeing on /cart/add appears to be a separate issue from the shipping rates problem in this thread.

Looking at the request logs for your x-request-id, the Origin header is coming through as http://127.0.0.1:9999 - requests from localhost to a production store will get rejected with 401. The storefront expects requests to originate from the store’s own domain.

If you’re doing local theme development, make sure you’re running shopify theme dev which proxies requests through the correct domain and handles authentication. If you’re running a separate local server that makes AJAX calls to the store, those calls need to go through the theme dev proxy or be made from the actual storefront context.

@PeterParker Sounds like what your seeing might actually be more closely related to the issue being tracked in this thread.

I’ve made the CLI team aware internally and they’re working on a fix. I’ll provide updates on that other thread if you’d like to follow along there instead!

1 Like

I have also been seeing 422 errors with no clear error message, just a generic Cart Error message.
This is an example request id: d303f122-3d13-49a2-8a56-f93bf2ca19cf-1769602454

The Cart API has been quite unstable in the past couple weeks, with also an incredibly annoying increase in 429 errors due to CloudFlare’s bot protection, which is particularly easily triggered when a customer is using a VPN.

EDIT:
The 422 error for that request id is due to the fact that the variant we were trying to add does not exist anymore. The error message could still be clearer on why the request failed.
The 429 errors are still an issue though :confused: (I have created a separate thread for it Aggressive bot detection with 429 errors AJAX Cart API)

Hey @Zak, thanks for sharing that request ID. I pulled the logs and can confirm this is a separate issue from the shipping rates problem that Sebastian reported.

Your 422 is on /cart/add.js, not async_shipping_rates.json. The logs show the request reached the server and was processed, but returned 422.

A 422 from the Cart API typically means one of a few things:

  • The product is sold out

  • Stock is already in the cart (you can’t add more of this item)

  • The variant isn’t available in the customer’s market

The Cart API reference documents the specific error messages for each case.

To dig into this further, we’d need access to the store context (inventory status, market configuration, cart state at the time of the error). Could you open a support ticket through the Shopify Help Center? That way we can look at the specifics of your store setup and what’s triggering these errors.

On the 429s from Cloudflare bot protection - that’s a separate issue again. If that’s causing significant issues, worth raising in the support ticket as well so we can look at the patterns.

1 Like

we ran into the same thing - “Can’t find variant -422” error out of nowhere on January 26th. Everything was working fine before that.

After digging into it, we found a nameless input field in our cart form was sending malformed data. To fix it quickly, we just bypassed the form submission and redirected straight to /checkout instead.

Feels like something changed on Shopify’s end with how the Cart API validates requests. Would be really helpful to know what changed on the 26th that caused this?