We recently introduced stricter bot protection, but it should not impact legitimate traffic for valid requests.
A couple of optimizations to consider:
If you’re still seeing issues with genuine requests, please contact support directly with reproduction steps so we can investigate the affected shop.
Hi @Paige-Shopify, thanks for responding.
I am mostly encountering the issue when testing our themes on both a development store and on a merchant store. We perform updates for existing clients that are running a custom theme and perform changes in our local dev environment. When running Shopify CLI and connecting to the store (both development and merchant) we are receiving these issues.
I do think it is great practice to enforce a type of debounce functionality into the code which this bot checking has forced us to do. However, even with debouncing and stopping user input for 1-2 second while cart updates occur, we still receive 429 responses.
We are getting 429 errors too, when simply doing a single await fetch(“/cart.js”).then(e => e.status) request.
but it should not impact legitimate traffic for valid requests
Exactly, but it does 
We use an app to Add To Cart.
We had a sale going the 11th-16th and our customers were complaining that they would click on Add to Cart and it just spins and spins, never adding the product to cart. They couldn’t add various products to their cart. We verified that on certain random products, this was indeed the case. Our app developers verified that they follow the standard steps. That customers emailed is amazing but most don’t. Our conversion rate was half what it was for the last sale. This is deeply and negatively affecting our sales, and therefore, Shopify’s revenues. Please implement fixes ASAP without negatively impacting our customers.
Thank you!
I can add to this, we have a client which recently also started to see this exact issue. It has been reported by multiple of their customers, so it’s not only when testing this happens. The client uses the premium theme Enterprise, and the theme standard code makes a GET request to “/cart.js” before AddToCart and another request to “/cart.js” after. I guess this is the reason they experience it more often, but this code is theme standard and have been running like that since march 2024. I tested the issue yesterday and I can confirm adding 5-10 products quickly after each other completely blocks AddToCart from our entire office (I guess it’s IP based)
Please fix this asap, seems like the request limit is way too low and it’s negatively impacting our clients
In my case I could only reproduce it in local environments, but around a week ago a merchant reported the issue too in their live store, all cart requests suddenly started responding 429 (without generating more than a couple requests a minute), and they weren’t using a VPN.
Thank you to everyone jumping in to share your experience with this.
If possible can you provide this information so we can investigate this further:
In the past week we are also started to experience the 429 errors on our app (on real-world stores). It’s absolutely impossible to complete finish a cart.
Even if we or customers use VPN they still hit the 429 rate limit error.
This breaks UX completely and we received lots of support issues because of this and there is nothing we can do.
Please fix and restore things to normal 
These are being spammed by /cdn/shopifycloud/storefront/assets/shop_events_listener-3da45d37.js, which I believe is a native shopify js script
@ewan-ante that file shouldn’t be making that many requests. Can you share a request ID of any cart action so I can investigate?
When checkout doesn’t trigger on a modified cart (especially one handling delivery dates), the issue is usually coming from one of three areas:
1. Cart validation failing silently
If the delivery date field is required but not properly validated before checkout is triggered, Shopify blocks progression without always showing a visible error.
2. JavaScript conflict
Custom cart scripts (AJAX cart, line item properties, or date pickers) can interrupt the /checkout redirect if:
The form submission is being prevented
An async call isn’t resolving
A recent theme or app update changed cart structure
3. Line item properties formatting
If delivery dates are being passed as line item properties, malformed data (e.g. null values, incorrect structure) can stop checkout from generating properly.
First things I’d test:
Disable the delivery-date script temporarily and attempt checkout
Check console errors on cart page
Confirm the cart form is still posting to /checkout correctly
Test on a fresh copy of the theme to isolate app interference
If this was working before, something likely changed, either a theme update or an app update affecting cart JS.
If you can share:
We can narrow it down further
Updated guidance for anyone running into 429 errors while crawling or running tests, please follow the approach outlined in this Help Center article.
We have been experiencing the same 429 rate limit errors for the past month.
Initially, after reviewing the theme code, we suspected the issue was caused by a third-party app related to the cart drawer. However, after thorough investigation, we were unable to isolate any specific app as the source.
To further validate, we deployed a fresh Horizon theme with all third-party apps disabled. Despite this, the issue persists.
Shopify Support has informed us that they are currently investigating the matter. They also mentioned that the problem appears more frequently when using VPNs or testing environments such as BrowserStack. However, we are observing the same issue on real customer devices as well, without VPN usage.
For reference, here is a video demonstrating the issue:
https://drive.google.com/file/d/1xZAiqrd7q0TZ4E6HEFdyhneoLW1blZ-9/view?usp=sharing
I am commenting here to share our findings and would appreciate any updates or feedback from others experiencing similar behavior.
This is still very relevant @Paige-Shopify. We just got another upset merchant saying that more than 20 customers reported they could not checkout due to continuous CloudFlare bot challenges.
Here is a message this merchant received from Shopify’s customer support about our app:
Reviewing it in technical terms, we discovered that this app makes too many calls in milliseconds to cart.js and I am detecting a problem of excessive polling of the cart associated with your app.
This is frustrating because this conclusion comes from what appears to be a shallow technical review. Our app does not poll the cart. Yes, we make a number of /cart.js calls, but many of those calls exist specifically to compensate for inconsistencies in the AJAX Cart API responses. We would happily make fewer calls if the API gave us reliable data.
More importantly, this is not just about our app. The Shopify app ecosystem has never provided a way for apps to coordinate with each other when interacting with the Cart API. There is no shared state, no event bus, no subscription mechanism. So every app independently fetches the latest cart data, which naturally results in a high volume of requests on any store running multiple apps. This has been the reality for years, and apps were built with the reasonable expectation that the Cart API could handle this kind of usage.
Increasing bot protection sensitivity without accounting for how the existing ecosystem actually works was not a well considered decision. The result is that legitimate customers on legitimate stores are being blocked from checking out. That is a real problem affecting real revenue for merchants who trust the platform.
It’s also worth pointing out that this is an ecommerce platform. Cart experiences can be very complicated, especially on stores running multiple apps that handle things like upsells, bundles, gift wrapping, subscriptions and so on. The Cart API should be built to handle high volumes of requests because that is the natural consequence of a rich app ecosystem. Imposing low rate limits on the Cart API and then blaming apps for hitting them is working against the very ecosystem Shopify built and profits from.
On top of that, the CloudFlare bot challenge behaviour is broken. Even after a customer successfully completes a challenge, they keep getting prompted again and again. A legitimate customer who has already confirmed they are not a bot should not be blocked from completing their purchase. That is driving away real paying customers.
These are solvable problems, but they need to be acknowledged first.
In fact, we have also encountered the same problem. Can we lift this strict robot restriction first? It has already affected our normal sales and has been affecting us for more than a month
Thanks everyone for continuing to share feedback on this.
We’ll keep refining these new bot protection measures based on what you’re seeing, so please keep the reports coming.
@Zak, on the Cloudflare bot challenge issue, could you share a bit more detail? For example, are users being prompted again right away, or only after a certain number of cart requests? If you can also provide the affected store’s myshopify.com address, we can review our logs to see what’s going on.
@Paige-Shopify
This matter is really serious and has already affected the revenue of our 4 stores this month. We hope Shopify can take it seriously and change the robot restriction to the previous logic to ensure our normal operation. We are very concerned about this issue. If it continues to cause a decline in our sales and affect customers’ trust in our store, we may consider not using Shopify again in the future. Please pay attention to this problem
@iven_lee, thanks for reaching out with feedback on this issue. We take loss of revenue very seriously. Have you created a ticket with support so we can investigate your specific case? If not, please open one and share the ticket number here so I can investigate further.
I have also experienced this recently (last 2-3 week) while using a vpn.
