there are multiple returning for background requests , 403 error is occuring for ajax api calls like cart.js and change.js after 2 or 3 attempts while on vpn, instead of json response we are receiving challenge from cloudflare , response is basically html with script inside ,response preview is same as before 'your connection needs to be verified before you can proceed ’
Thanks for sharing @Jeevan_Abraham_Joji!
We’re looking into this now since it appeared as a result of resolving this issue.
Related thread here:
Hey @Paige-Shopify
The specific 403 issue has been reported here: Shopify Ajax API returning Cloudflare 403 verification errors
Thanks for sharing @ayoub, I’ll review the reports in that thread as well.
Hey team,
The captcha checks are really frustrating 
and we’ve started to receive complains from merchants again. What’s happening? If our app is doing some updates, but if there are other apps which are doing updates, everything breaks.
If we change to GraphQL instead of using the public Cart API would this issue be fixed?
Thank you for your hard work on this!
I can’t even load some shops anymore.
All it takes is clicking add to cart once to get spammed with 1000 “verify you’re human prompt”
@app Can you confirm if you’re still seeing this issue on these shops?
I’m still experiencing when I use VPN, so it affects my development.
However ,the merchant said this: “I have never come across a Recapcha check with my site in the past month.”
We fixed our cart drawer from getting frozen when a 429 was returned with a fetch interceptor to reload the page and show the reCaptcha page. Now, the store is reloaded automatically and I can click on “Verify you are human”.
The main problem is that this verification is not persisted, so I get it every 2-3 minutes. There are multiple apps which are checking the /cart api but I guess they are coming from my VPN IPv4, so the system thinks I’m a bot. However, why the verification is not persisted? Maybe the timeout for this would be 10-30 minutes would be much better (if that’s even possible)
if ("function" == typeof callback) {
object.fetch = function () {
var tokens = arguments;
return callback.apply(this, Array.prototype.slice.call(arguments)).then(function (res) {
if (res.status === 429) {
const url = typeof tokens[0] === 'string' ? tokens[0] : (tokens[0] && tokens[0].url ? tokens[0].url : '');
if (url.includes('/cart')) {
window.location.reload();
return new Promise(() => {}); // Halt promise chain
}
}
if (!res.ok) { return res; }
If more apps or theme scripts sending multiple requests, eventually one fetch request will trigger the 429.
I’m using a dedicated ip for the VPN from a popular hosting company (DO) and it wasn’t changed in 2 years, so the IP might be flagged at the subnet level by Cloudflare. I don’t know exactly how this can be fixed. Maybe, adding the IPs to the partner dashboard, they could be whitelisted.
Thank you very much for looking into this.
I’m all noticing many apps using a fetch interceptor but a lot of bad apps are just spamming cart calls.
Shopify could just add a native way to do it, and solve the problem.
Thanks for sharing. It’s good to know merchants are using fetch interceptors to preserve the cart experience when a 429 is returned, since that speaks to the impact this is having.
For VPN traffic, we don’t have a complete solution yet, so VPN users may still see these challenges more often for now.
I agree it would be better to have a platform-supported pattern for apps that need to read or update the cart.
@app could you share a couple of request IDs for a successful cart request right before or after the issue occurs? The more logs we can review, the better. Thanks!
Thank you for looking into this.
Page load event, and there were several fetch requests to /cart.js by the theme / apps:
fb5883f2-a356-4c58-8247-439f1bba9b92-1783039843
658752fa-83cb-4bef-8603-f9dc14a36f24-1783039843
1118f7a1-52bb-41d6-9dfa-87429728a6bd-1783039843
0d312dae-5cb4-435c-b92b-bb4090faf844-1783039843
455deff8-057a-4703-8352-14d2b380bf1c-1783039844
3fabd205-3f4c-4438-8fde-af396c014649-1783039844
a1d33a36-6598-4afd-8bb8-d168d1a4482d-1783039844
362f2397-cee7-44f8-bbe0-745e9f22e48d-1783039844
403298e8-0b4c-4d92-9be8-84ed5ffb4e03-1783039844
f9895827-d1c8-4317-910b-fdd562667402-1783039844
9181d11a-f4f4-468d-a7fd-bec8210f5137-1783039844
2fc53eec-d9b7-4b0d-b83a-9ed8a341ae5d-1783039845
c5122789-c3d4-45e3-9bbb-c1454071a735-1783039845
The next 3 ones returned 429 with no request id.
Cf-Ray: a151e5e398eb50d5-LHR
Cf-Ray: a151e5e398ec50d5-LHR
Cf-Ray: a151e5e398f150d5-LHR
Recaptcha accepted, then several cart requests worked ok.
ec22ef31-8d93-4a39-9c02-600a81d0096f-1783040119
06f9369f-5e69-47c9-8072-4d76a6cb6370-1783040119
3f7f857c-8eae-4821-91b6-f09cddaca9ca-1783040119
2c0167cc-e729-43a1-8a89-d193c8a49efa-1783040120
The next one returned 429 → Cf-Ray → a151ec93da0760f8-LHR
The next one returned 429 → Cf-Ray → a151ee3bcc327701-LHR
I think I can export the .har file from devtools if needed.
Thank you!
I’ve been having issues since saturday. The ast two days sales have tanked. Been bounced around and not really given any help. Only managed to get them to believe me there was an issue once I recreated it myself on the site after days of testing.
Because Shopify will try and gaslight you into believing this issue is fixed here is the recording from their own team showing the breaks everyone is talking about above. Support couldn’t even be bothered to watch their own video showing it and instead told me it has not affected my sales or my cart… SHOPIFY AGENT BREAKING CART
To clarify the current status:
-
Fixed: The regression that caused widespread 429s for real customers during normal cart interactions has been fixed. Normal cart activity should not generally trigger a 429. If it does, please share request IDs and reproduction details.
-
Expected behavior: 429s can still be returned for bots and automation-like traffic, such as rapid, repeated add-to-cart requests. They may also be triggered when multiple apps make frequent cart requests. Storefront crawlers, testing scripts, and other automated tools should use Web Bot Auth to securely authorize their requests so they can be verified as coming from an authorized source.
-
Not fully resolved: Some VPN users may encounter these challenges more often. VPN use does not automatically result in a 429, but there is not yet a complete solution for false positives.
-
Mostly resolved for Shopify CLI: Upgrade to Shopify CLI 4.4.0 or later. These versions attach request signatures during
shopify theme devwhen using the default authentication method, making legitimate CLI traffic less likely to be rate limited. This does not yet apply when using--passwordwith Theme Access. More details are available here.
Thanks for your patience while we continue improving the bot protection experience.