We received an API deprecation warning for our app (with delisting threatened after October 1, 2026) for Storefront API calls our app doesn’t make.
What happened
Our API health report flagged CartDiscountCodesUpdate.discountCodes. We audited our codebase and deployed extension bundles: we removed all usage of cartDiscountCodesUpdate months ago, and every call we make is pinned to API version 2026-04.
After support shared the affected shop domains, we traced the calls to a third-party integration script. Merchants had copy-pasted our app’s public storefront access token into that integration’s configuration, and all of its traffic was attributed to our app.
The problem
Public storefront tokens are public by design. The docs explicitly describe embedding them in browsers, and any cart app querying the Storefront API client-side must render its token into the page. But that means any script on the page can lift the token and use it, and every call it makes lands on the token owner’s API health report. So an app can face delisting warnings for traffic it has no control over and no way to trace without a support ticket.
Questions
Is there any way for an app or merchant to check which app owns a given storefront access token? shop.storefrontAccessTokens only returns the requesting app’s own tokens, and the Storefront API has no token introspection as far as we can tell. If ownership were verifiable, integrations could refuse tokens belonging to another app.
Could the API health report include request metadata (origin, user-agent, or a per-shop breakdown) for flagged calls, so token owners can find third-party usage themselves?
Could deprecation enforcement distinguish first-party from third-party traffic on a public token before penalizing the app that owns it?
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.
We’re facing the same issue. I think in general though it seems odd that these third party’s are just picking up tokens from the page and using them.
Given that there was a possible threat of de-listing due to them making deprecated calls, I was thinking that the simple solution was to obfuscate the token. For example, just reversing the token and then reversing it back when you make the call.
Obviously they can still see the token over the wire but my assumption is that they are regexing the tokens out of the page.
Hey — I came across your post about getting a deprecation warning for Storefront API calls your app doesn’t make, with the discountCodes field flagged even though you’d removed that usage months ago and pinned everything to 2026-04.
I’m researching how Shopify developers debug these cases, so I’m curious what happened after you posted. Did you manage to prove it was third parties reusing the token, and did that get you out of the delisting path?
The part I’d most like to understand: once you suspected the calls weren’t yours, how did you actually go about tracing them? I’ve seen a few teams hit this and every one of them seems to have invented their own method.
No product, nothing to sell — I just want to hear what the process actually looked like.
One partial mitigation that actually does something (unlike reversing/obfuscating the string, which is still visible over the wire): rotate the public token with storefrontAccessTokenCreate and delete the old one with storefrontAccessTokenDelete. Any copy sitting in a merchant’s third-party script goes dead right away, so it caps how long a leaked token keeps generating calls against your health report, even though it doesn’t solve attribution or let you identify the source ahead of time.
We’ve confirmed a detection bug affecting CartDiscountCodesUpdate.discountCodes warnings. Calls served on Storefront API versions before 2026-01 can trigger the warning even when they correctly supply discountCodes, including []. This could be the reason for some of these flags you’re seeing.
For enforcement, @Donal-Shopify’s September 9 clarification says deprecated calls made by a third party using your public Storefront token don’t, by themselves, result in enforcement against your app. Unusual token activity can prompt a review, but that’s an outreach step rather than automatic delisting. Your own implementation still needs to supply discountCodes on 2026-01 and later.
API Health doesn’t currently provide a self-serve breakdown of the originating store or third-party caller, and Support can’t disclose those stores’ identities. I’ve submitted a feature request for additional attribution tooling as well.
Under the standard version schedule, older requests are expected to be served as 2026-01 from October 16 at 15:00 UTC. If you see new detections after that, please reach out in an authenticated Partner Support conversation so we can review those examples.
@Wes-Dev-Shopify What is this “API Health” you speak of? Old Partner UI, or something internal? The current instance of the Dev Dashboard has none of this - just an ‘Alerts’ column on the app list and some banners on the app overview page…
Hey @Kyle_W - my apologies and thanks for catching that.
I used the old Dev Dashboard terminology. I should have referred to the deprecated API call alerts in the Dev Dashboard’s Apps list and app Overview banners.
My wording made it sound like there was a separate API Health report you could open. The feature request I mentioned is for more actionable detail behind those alerts, so developers can investigate the calls attributed to their app.
Hey folks - we’ve seen reports in this related thread of merchant-facing “This app is unsupported” warnings now appearing during app installs alongside these deprecation alerts.
We’re investigating and will follow up as soon as we have more to share.