Issue with ajax cart API async_shipping_rates.json

Short description of issue

async_shipping_rates throws error

Reproduction steps

call prepare_shipping_rates → 202 accepted
call async_shipping_rates → error

Additional info

started sometime today

What type of topic is this

Bug report

Seems like the issue is two-fold.

prepare_shipping_rates seems to have changed to return nothing at all (i note the API docs currently states this), however getting multiple merchants report the shipping rate estimator (using the old shopify supplied code) no longer works as of today, so appears this has been rolled out today and likely has broken many stores.

second issue is async_shipping_rates always returns an error even after prepare_shipping_rates has been called successfully (and i can confirm rates have been calculated on the backend too)

Hey @Min_Liu, thanks for the report! I tried the prepare_shipping_ratesasync_shipping_rates flow on a test store just now and the endpoints are responding correctly on my end - prepare_shipping_rates returns 202 with an empty body (which is expected per the Cart API docs), and async_shipping_rates returns the rates JSON after polling.

That said, I can’t rule out something changing that affects specific configurations. To dig deeper, could you share:

  1. The exact error response you’re getting from async_shipping_rates - the full JSON body, not just “error”

  2. An x-request-id from the response headers of a failed request (visible in browser dev tools Network tab)

  3. A store URL where this can be reproduced, or the specific code/theme snippet you’re using for the rate estimator

Once I have those details I can investigate the specific requests in our logs and see what’s happening server-side.

Hi @Donal-Shopify is there any way to PM these details to you as they contain merchant data and thus sensitive.

1 Like

Sent you a DM here on the forum, will be happy to take a look!

I am getting the same error all of a sudden on one of our apps and it is not related to our codebase, seems like the api has changed something, trying to figure out what exactly is the issue.

Hi guys! Same here. In touch with Shopify Support

I wanted to chime in with some nuanced behaviour I’ve noticed.

If you receive the 422 error, then head to the checkout and receive a shipping rate there, then return to the cart page and try generating rates, you will get the rates received in the Checkout. I also noticed that the received rates are the same as the Checkout regardless of the entered destination data, which seems like a cache issue.

On my own test shop I don’t get the 422 error - I actually received a valid rate request for my Canadian shipping address, then I turned around and entered an American address and still received the Canadian shipping options, which seems like the same cache issue mentioned above. This only happens with the Cart API, not in the checkout.

Lastly, I noticed new fields in the async_shipping_rates.json response, which suggests there has been some changes that aren’t in the docs yet, but may be unrelated. :eyes:

Hey everyone, thanks for your patience on this - I raised it internally and the team identified a change that was causing the 422 errors. They’ve rolled it back, so this should be working again now.

@Min_Liu @mtk777 @Lucas_Vida @NickLozon - can you confirm things are back to normal on your end? The prepare_shipping_ratesasync_shipping_rates flow should be returning rates as expected again.

Appreciate the detailed observations in this thread, especially the caching behavior notes - that helped narrow things down.

Working for me, thank you for the speedy turn around!

1 Like

Hi @Donal-Shopify working for me. Thanks for the fix.

1 Like

Hello @Donal-Shopify Everything works now. Thank you so much for your helping.

1 Like

@Donal-Shopify Yes, it’s working now. Thank-you very much!

1 Like

Hi @Donal-Shopify this seems to have occurred again, prepare_shipping_rates is returning nothing rather than ‘null’ again.

1 Like

I everybody, how are doing? I hope well. So, we have same problem too like @Min_Liu . Any update about this?

1 Like

Hey folks, thanks for the follow-up details and fresh request IDs via DM - really helpful.

I’ve raised this with the Cart team again to see if this is a reemergence of the previous issue or something else. I’ll update this thread once I hear back.

Hey @Min_Liu , @Lucas_Vida - I raised this with the team and the underlying change has been rolled back again, so prepare_shipping_rates should be returning the expected response. Can you both confirm things are working as before on your end?

One thing that would help the team going forward - when you noticed the issue this time around, was the shipping rate estimator actually broken for your store visitors (i.e., they couldn’t see shipping rates on the cart page), or was it more that you spotted the response body had changed while inspecting network requests?

The team is trying to understand the real-world impact to prioritize the right path forward here - thanks again for your help!

Yes looks like its working, thank you.

And yes, the shipping estimator on the theme throws an error, I believe the snippet of code they are using is the one posted on the shopify forum a while ago written by a Shopify staff member so probably widely used still.

The code tries to run eval over the response to convert it to json as it expects the API to return ‘null’, when this is blank, this throws an error.

If the intention here is to change the API response, perhaps this should be communicated more thoroughly rather than just suddenly changed.

Further, this issue actually has nothing to do with our app, but as our app produces shipping rates, merchants report the issue to us as we are the closest service provider, these merchants may have had these snippets included with a theme, or put in by a developer when they setup their site or last updated their theme design, but otherwise have no ongoing development support and thus if the API were to change they will likely not receive communications that such a change will occur and be able to rectify before such change is rolled out.