Cloudflare has closed the bot‑management incident, but the Ajax API issue is still occurring. This suggests the problem likely isn’t directly related to the original Cloudflare bot‑management issue.
Update 1:
Cloudflare has just updated their status page, confirming that this is an issue caused by false‑positive bot protection rules: https://www.cloudflarestatus.com/
Over the past few hours, we have observed a significant increase in Shopify Ajax API failures caused by Cloudflare 403 responses with the following message:
“Your connection needs to be verified before you can proceed”
Impact
This issue is heavily impacting merchants using our app, as requests to Shopify Ajax endpoints are intermittently blocked by Cloudflare verification challenges. As a result, core storefront functionality depending on the Ajax API is failing for affected stores.
Observed Behavior
Shopify Ajax API requests intermittently return HTTP 403
Response body contains Cloudflare verification message
Failures started increasing during the past few hours
The issue affects multiple merchants and stores
Expected Behavior
Shopify Ajax API requests should complete successfully without Cloudflare verification interruptions for legitimate storefront traffic.
Additional Notes
Given the scale of impact across merchants, this appears to be a platform-level issue rather than store-specific behavior. We would appreciate investigation and guidance on mitigation steps.
Facing the same issue. The online store loads, but the ajax APIs fail. So it looks like the site doesn’t work. There’s no way to verify the connection without reloading the page and there’s no reason for a user to reload.
In some cases, the captcha comes on the initial load itself - which is still ok, the user can verify connection.
Thanks for sharing your solution, but this thread is not about the dev environment or 429 errors. This is a production issue impacting Shopify stores at a very large scale. Cloudflare has just confirmed the incident and stated that they are working on it: https://www.cloudflarestatus.com/
You’re right, the issue is still happening on our side as well. It doesn’t really feel like it’s being taken seriously yet, even though it’s affecting a lot of Shopify stores that rely on the Ajax API.
The issue is affecting real customers at scale worldwide. It appears to be resolved for Asia, but we are still seeing it in several European and African countries. As a temporary workaround, we have switched to the Storefront Cart API while we wait for a permanent fix.
If any customers are experiencing 403 verification errors, have the merchant reach out directly to support. We’ll need to investigate the AJAX API calls on these shops on a case-by-case basis.
Starting on May 14 around 10 PM, we received over 100 support tickets in less than 15 minutes. After investigating for a few hours, we identified the cause as Cloudflare bot challenges affecting the Ajax API (403 error). As a workaround, we switched to the Storefront API, which does not appear to have this limitation. We were able to fully resolve the issue within a 5‑hour window, but during that time we received more than 500 tickets from merchants all over the world impacted by this issue.
Yes — you’re absolutely right, and I was about to surface the exact same finding. Our testing points squarely at /cart/clear.js as the trigger. Here’s how we confirmed it:
Test 1 — with clear.js:
Cleared the store cookies.
Reloaded the page.
Called /cart/clear.js (worth noting: it’s unusually slow on this first call).
Then called /cart/update.js several times — every call returned 403.
At that point, refreshing the page triggers the Cloudflare challenge.
Test 2 — without clear.js:
Cleared the store cookies.
Reloaded the page.
Called AJAX cart endpoints other than /cart/clear.js directly — all worked fine, no 403s.
Conclusion: Calling /cart/clear.js appears to put the session into a bad state where every subsequent call to any AJAX cart endpoint returns 403. Simply avoiding that one endpoint makes the issue disappear.
To answer your question directly: yes, our app currently uses /cart/clear.js (to reset the cart before adding items in some flows).
