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.