Hi,
Due to business logic errors during early development, some stores’ legacy tokens were lost and never saved in our system. These stores have never uninstalled our app, and the merchants haven’t opened the app since. As a result, we can’t run the token exchange (there’s no old token to start with).
Our question:
Has this scenario — stores that never uninstalled the app but whose legacy tokens are irretrievably lost, with no merchant activity — been considered in the migration requirements?
My understanding is that the requirement should apply to API calls made using active tokens, rather than the full list shown on dev dashboard.
What matters is whether non-expiring tokens are being used, not if they exist at all. The Dev Dashboard will show alerts if any non-expiring tokens have been used to make API requests in the past 14 days.
However, be mindful that if you have older non-expiring tokens in an “inactive” state they represent a latent concern for your app. If they’re “accidentally” used in the future they will trigger an alert.
You can use application-only access token acquisition to acquire tokens for shops that don’t have merchant activity.
Your app won’t be punished for having old installs with inactive access tokens, but if those shops become active and the non-expiring tokens are used that will trigger an alert.
Any guidance on when shopify-app-php will be updated for application-only token acquisition?
Just to clarify: would the safest approach be to completely remove any remaining legacy non-expiring offline tokens from our database, especially for stores where migration hasn’t been possible?
This would mean background tasks would stop working for those stores, but if a merchant eventually reopens the app, we could reauthorize them and generate a new pair of expiring access and refresh tokens.
Would this guarantee that our app remains compliant and avoids delisting on January 1st, even if some stores have never completed the migration?
I’m asking because I’d rather have background tasks fail for a few inactive stores than risk having the entire app delisted due to a legacy token being used accidentally.
Hey @TerenceShopify , I migrated all my apps a few months back as well, and haven’t had any warnings on the dev dashboard since, including now.
However, I’ve just received an email saying legacy tokens have been used in several of my apps over the last 14 days.
Has this email been sent in error? If not, why is it reporting something different from the dev dashboard? It looks like quite a few other developers are experiencing the same issue, so it would be good to get some clarification!
Yes, you could do that. Alternatively you can exchange the old non-expiring tokens without needing any user involvement following this process. This approach is designed exactly for the scenario you describe where apps are not actively used by a merchant but might have periodic background jobs that run. The app should defensively check that it’s only using expiring tokens, but by exchanging all of the non-expiring tokens you can establish a “clean” environment for the app and hold only expiring tokens.
The counts in the email include tokens that are active (i.e. they haven’t been revoked, deleted, exchanged for expiring tokens). The dev dashboard shows alerts when there have been non-expiring tokens used to make API requests in the past 14 days. So an app that still has “active” but dormant non-expiring tokens would be included in the email but might not have any active alerts in the dev dashboard.
Hi @TerenceShopify, we’ve successfully migrated our public app to expiring offline access tokens many weeks ago but received email notice yesterday of the impending Jan 1, 2027 deadline and consequences, along with a note saying that there were still 109 tokens to migrate.
I ran it through my DB and agent and found that 96 of these cases were from stores that are no longer available, either closed, locked, or frozen. And when attempting to migate these tokens the request fails due to 403 “Unavailable Shop”, 404, or 423, with their storefronts showing “This store is unavailable”.
My questions are:
@TerenceShopify I got an email saying an non expiring token was used once, although the dev dashboard doesnt show any use.
is there some kind of threshold that triggers the dev dashboard, and will there be a similar threshold on enforcement? this instance was most likely manually run using stale credentials, we’ve gone ahead and deleted these across all our systems now, but it would be less than desirable if accidents like this caused delisting.
Can you share request IDs for these failures so we can investigate? Exchanging non-expiring tokens for expiring tokens should work even if the shop is in a dormant state.
Yes, the dev dashboard alert will fire when a non-expiring token has been used to make an Admin API request in the past 14 days.
Thanks for looking into this, here are request IDs from our server’s real migration attempts (non-expiring → expiring token exchange with our app’s credentials), 2026-10-30 at about 16:00 UTC:
{"errors":"Unavailable Shop"}: d2d94874-5fe9-4ad0-b6e9-530e2da54a34-1793376045c360ceb0-78ab-4080-be1c-9ed9da345ba5-1793376049{"errors":"This store is unavailable"}: 23ee3ce2-1119-4a90-ad37-1e3f64b96bc3-1793376048All 96 of our remaining tokens failed the same way (92× 403, 2× 404, 2× 423), and none converted. Every one of these storefronts shows “This store is unavailable”.
This being the case can you help me to understand why our email says:
You have 1559 tokens to migrate. These tokens were used by 919 shops over the past 14 days.
And yet the warning on our dashboard disappeared weeks ago after we migrated all merchants (barring the one who’s shops were disabled in some way). I’d like to understand if the email is incorrect here or the dev dashboard is?
In our integration the only time an old style token will be used is for a token exchange.