We have been receiving more and more complaints of merchants seeing their cart crash due to 429 errors, not only on the /cart/add.js and other mutation endpoints, but on the /cart.js endpoint as well.
The issue is particularly visible when connecting through a VPN (I have used NordVPN P2P connection to US servers) and opening the store in an incognito window. After a couple minutes of normal usage, the Cart API start returning 429 for all its endpoints with the CloudFlare bot challenge and the message Your connection needs to be verified before you can proceed.
225f80cd-fc9f-4dd7-8ad1-49f6ceaf57d0-1769608128 this is an example of the last request id for a /cart/add.js request before CloudFlare started blocking all subsequent requests. This does not seem to affect the storefront API.
We are getting this issue on a Florist website which has a modified cart to deal with delivery dates. Customers are unable to get through to the payment page. Leading up to Valentines day, this is a major issue for us.
We’re experiencing widespread 429 errors with Cloudflare bot challenges on Cart API endpoints (/cart.js, /cart/add.js, /cart/change.js) across many stores.
After a short period of normal browsing, all cart requests start returning “Your connection needs to be verified”, fully breaking add‑to‑cart and checkout. This now affects read endpoints (/cart.js) as well, not just mutations. Storefront API calls continue to work.
Repro patterns:
VPN traffic (very common with real customers)
Incognito / fresh sessions
Local development environments
Custom cart logic (delivery dates, etc.)
This is impacting hundreds of stores, especially US traffic, and is actively blocking real customers during peak sales periods.
This appears to be over‑aggressive Cloudflare bot detection or rate limiting applied to Cart API endpoints.
Can you please:
Confirm this is a known issue
Share whether Cart API / Cloudflare rules changed recently
Provide mitigation guidance or recommended request limits
Clarify whether Cart endpoints can be exempted from bot challenges
This is currently a storefront‑breaking issue with no reliable workaround.
It’s expected for bot detection to kick in when the exact same request is sent multiple times in a short period.
For example, this typically passes since the requests are different:
Add 1 of variant A
Add 1 of variant B
Add 1 of variant C
But this can get flagged as the same request is repeated back-to-back within a short window:
Add 1 of variant A
Add 1 of variant A
Add 1 of variant A
Add 1 of variant A
Add 1 of variant A
Add 1 of variant A
Add 1 of Variant B
Add 1 of Variant B
Add 1 of Variant B
Add 1 of Variant B
Add 1 of Variant B
Add 1 of variant C
Add 1 of variant C
Add 1 of variant C
Add 1 of variant C
Add 1 of variant C
If any part of your code is sending the exact same request repeatedly in a short period, it’ll need to be refactored to reduce those repeated calls.
I checked the logs for request ID 225f80cd-fc9f-4dd7-8ad1-49f6ceaf57d0-1769608128, and it shows the same request being made multiple times within the same minute:
@Paige-Shopify this was never an issue prior to around January 24th and is still not an issue in most of the regions, because I only run into this issue when I’m using a VPN and particularly easily if connected to a US server.
Something has clearly changed either in Shopify’s bot rules or from CloudFlare’s side.
Merchants that were using our app for months with absolutely no issue started complaining during the same week about their customer’s not being able to shop due to rate limits, so it’s clearly not expected.
I get if a store would get rate limited after 16 requests to the same endpoint in a row, but it literally gets blocked after 2 requests.
This has been experienced by multiple people, both in local development as well as production, all with similar common traits (US market, VPN etc), so there is clearly an issue.
@Paige-Shopify I can also confirm this happening to live & preview themes when using Nord VPN (set to Australia). I have some clients where I couldn’t even add 2-3 different products / variants inside 30sec window. Without VPN, it seems fine on live sites.
Thanks for sharing this context @Zak and @_vi
We’d like to dig into this further so we can address the root cause.
If you’re comfortable sharing the affected shop’s myshopify.com URL, I can send each of you a DM to collect it.
@Paige-Shopify the issue is still happening on the store I have shared with out in PM. It’s very easy to verify, just connect to NordVPN US server, open an incognito window and interact with the store by adding one item and then increase its quantity one time. You’ll quickly see that 429 errors start flooding the network tab of the dev tools.
@Paige-Shopify I develop custom themes for Shopify and have recently been facing this exact issue. Even if it was isolated to the development environment only, this restrictive bot detection makes it terrible to develop a custom Cart Page. I even added debounce functionality to avoid overloading cart update requests and I still receive this “Your connection needs to be verified before you can proceed” page with a Cloudflare turnstile that never renders to the screen. I am forced to mask my IP address to re-test the page designs and functionality.
Developers and customers are literally reaching a screen that is a dead end and negatively impacts user experience massively.
I understand bots have become a problem but this needs to be flagged as an important issue as it impacts both customers and developers.
@Zak, I’ve had a look at that shop and this is what I’m seeing:
/add.js - Add product A to cart
/change.js - Change quantity from 1 to 2
/update - Update quantity from 1 to 2
/change.js - Change quantity from 2 to 3
/update - Update quantity from 2 to 3
It appears both the update and change endpoints are used at approximately the same time to make the same change/update to the cart, leading to 429 responses.
Thanks for sharing your experience with this issue as a custom theme developer.
Are you mostly encountering this issue when testing your theme? Are you testing on development shops or merchant shops when the issue occurs?
I understand, but this was never an issue before and lots of cart experience are built on complicated use of the Cart API.
The use of the Cart API is not limited to simple cart additions or quantity changes, due to multiple apps having to cooperate without clean standards and due to having to work around lots of Shopify limitations and bugs, the use might not be as simple as you’d expect it.
5 requests to the Cart API should absolutely not trigger bot protection.
Shopify stores often require complex workflows, for example require updating cart level attributes (which can be only done with the update.js endpoint) after maybe the cart quantities change (maybe the native theme cart uses the change.js endpoint), then maybe there is another app that listens for cart changes and trigger a free gift addition using the add.js endpoint).
Cart experiences are not as simple as you might think, so for 5 requests to trigger bot protection seems quite surreal, since this was never an issue before a January 24th.
I hope you’ll see reason and fix this, because as you saw yourself, the issue does still exist on live merchant shops and 5 requests should not cause a customer to not be able to shop at all.
Agree with @Zak that this was not an issue before Jan 24th.
Testing and site monitoring has become a problem as BrowserStack and other site monitoring tools (Sematext) are unable to proceed with any cart requests anymore. I’m seeing 429 responses even on the initial cart request when using these tools.
