Our app’s Dev Dashboard → API health is flagging a deprecated Storefront API call:
As of API version 2026-01, the cartDiscountCodesUpdate mutation will require the discountCodes argument.
Endpoint: CartDiscountCodesUpdate.discountCodes · Storefront · GraphQL
The issue: our code never calls cartDiscountCodesUpdate anywhere. We’ve searched our entire codebase and confirmed it — we don’t use this mutation at all. Yet it keeps getting reported against our app.
Our questions:
Attribution: How is a Storefront API deprecation attributed to an app? What exactly causes a call to be counted against our app in the API-health report?
Source store: The API-health report is aggregate (endpoint + last-detected only). Is there any way — dashboard, Admin API, webhook, or Partner support — to see which shop(s) the flagged call came from? That would let us narrow it down.
Impact if ignored: What actually happens at the 2026-01 cutoff for a call we don’t make? Could our app get marked “Fix overdue” / face delisting because of it, even though it’s not in our code?
Anyone else? Is anyone else seeing a Storefront deprecation (especially cartDiscountCodesUpdate) attributed to their app for a call they don’t make? How did you investigate or resolve it?
Any guidance from Shopify staff or other partners would be much appreciated.
Hey @Rohan_Vasava, good questions! As of the 2026-01 Storefront API version, cartDiscountCodesUpdate requires the discountCodes argument. Before that, a call omitting it was accepted but was effectively a no-op, so this often shows up from older calls that previously did nothing.
API health reflects any call made with your app’s access tokens in the last 14 days, not just calls from your app’s own server code. For a Storefront mutation like this, that means anything sending your app’s Storefront access token counts toward your status, for example a theme app extension or app embed, a headless storefront using the token, or even testing via an HTTP client like Postman or Insomnia. So your code never calling the mutation directly and the warning still appearing are not contradictory.
There’s no self-serve breakdown of which store or request triggered it, but our support team can check the logs on our side and trace the offending call back to a store/user agent etc. I’d reach out to Shopify Partner support and include your app’s client ID and the exact warning you’re seeing so they can correlate it.
No problem! Once you’re logged in with an account associated with the Partner organization that owns the app in question support will have a lot of context already. If you could share a link to the affected app as it appears in your Dev Dashboard along with the above screenshot that’d save them some time!
Just following up on this, is there any update or guidance available? I’m still seeing the deprecation warnings across the three apps and would really appreciate any pointers on how to identify the source store(s). Thanks so much for your help!
Our own Storefront API client is pinned to version 2026-04 and makes queries only (product/config reads) - it never calls the cartDiscountCodesUpdate mutation anywhere in our codebase.
I think the reason these calls are attributed to us is structural: our app publishes a public-read Storefront access token in the shop’s page source so our widget can read product data. Shopify attributes every Storefront API call to the app that created the token, not to the script that actually fires it.
Any third-party integration on the store (page builders, email/CRM tools, mobile app wrappers, custom theme code) can pick up that publicly-readable token and make its own calls - and those then show up in our deprecation report.
By definition the token is meant to live in the browser:
Public access tokens enable your app to make Storefront API requests from public contexts like a browser.
Once the token is in the browser, the owning app loses all control over it. Any script on the page can pick it up and use it, and every call it makes is attributed back to the app that minted it.
Ideally, apps and integrations would be required not to use tokens minted by other apps. But even a well-intentioned integration can’t comply today, because there’s no tooling for it: there is no API to check who owns a storefront access token, so an integration that asks merchants to paste one has no way to tell whether it was minted by the merchant’s own custom app or belongs to a third-party app.
Update: got a response from Shopify Partner Support:
The calls are being attributed to your app because third parties are reusing your public Storefront token, which is expected behavior by design. Shopify accepts that risk when issuing public tokens, and deprecated calls made by third parties using your token will not result in any enforcement action against your app. The warning on your Dev Dashboard is informational only and is not an enforcement trigger
You are safe to ignore that warning as long as your own codebase does not call the deprecated mutation past its removal date
API health status reflects any call made with an app’s access token in the last 14 days, not only calls from the app’s own server. A third-party script reusing a public Storefront token can produce the warning against the token-owning app. The API health report docs cover the attribution mechanism.
On enforcement, deprecated calls made by a third party with a partner’s public Storefront token don’t, by themselves, result in enforcement against the app. The warning is informational in that scenario. The one caveat is that unusual token activity can prompt a review, but that’s an outreach step rather than an automatic delisting.
The practical takeaway is to make sure your own code doesn’t call cartDiscountCodesUpdate without the discountCodes argument on API version 2026-01 or later, where the argument is required. As long as that’s clean, the third-party-triggered warning is safe to leave.
Hey @Donal-Shopify, jumping in we’re dealing with the exact same thing.
One difference for us: our app does use the cartDiscountCodesUpdate mutation, but always the correct way with the discountCodes argument. So the deprecated calls still aren’t coming from our code, it’s third parties reusing our public Storefront token, same as everyone else here.
The confusing part: when we contacted Partner Support, we were told that if the deprecated calls persist past the deadline, our app could be delisted, blocked from new installs, or merchants notified. That’s the opposite of the “it’s informational only, safe to ignore” answer others in this thread got.
So we’re not sure what to believe. Rotating the token isn’t a real fix (anyone can just grab the new one), and we can’t control who reuses a token that’s public by design.
Could someone from Shopify staff give a definitive, on-the-record answer? Specifically, do third-party deprecated calls with our public token actually risk delisting or not? And does it matter if the app genuinely uses the mutation correctly vs. never calling it at all?
Our Partner Dashboard flags the deprecated cartDiscountCodesUpdate (missing discountCodes), but our code already uses the discountCodes argument correctly, so the calls aren’t coming from us.
They’re from third parties who scraped our public Storefront token and are reusing it on older API versions or something like that.
The dashboard doesn’t show which stores are making the calls, so we can’t identify the source.
Also, since the Storefront access token is public by design and can be reused by anyone, the app shouldn’t be held accountable for calls it didn’t make — right?
Hi @Sabarinath and @naveen_dev - I appreciate you following up here, I know it’s confusing to get conflicting information. Without seeing the support ticket to confirm, it sounds as if the general deprecated API call guidance was relayed, rather than the guidance specific to this deprecation and call attribution that we’ve discussed above in the thread.
As of today, the below still stands:
There’s no self-serve breakdown of which store made the calls. To have the source identified, contact partner support (https://help.shopify.com/en/partners → Chat with a human) with an app identifier (App ID, Dev Dashboard URL or Client ID) and they’ll be able to check the logs in that authenticated support session.
We’re running into the same issue as everyone here re: the deprecated cartDiscountCodesUpdate call. Similar to others, we haven’t made this API call and we believe it’s a storefront using a publicly available access token.
Our apps now have a “This app is unsupported” banner and partner/developer support is not helpful - all I’m seeing are responses written by AI and generic support.
@Donal-Shopify We are running into the exact same issue as well. Our app does not make any calls to `cartDiscountCodesUpdate`, but because someone is making those calls using the public storefront access token, those calls end up attributed to our app.
This has caused our app to now show “The app is currently unsupported” warning on every install, which is very problematic. Could you please provide more guidance on how to resolve this? Thanks!
We’re aware that some of you are now seeing merchant-facing “This app is unsupported” warnings during app installs, even though your apps aren’t make the flagged calls.
We’re looking into this and will follow up as soon as we have more to share.
