Action required: migrate to expiring offline access tokens before January 1, 2027

If your public app still uses non-expiring offline access tokens, complete migration before January 1, 2027 to keep it listed in the Shopify App Store and continue accepting new installs.

Expiring tokens reduce how long a leaked access token can be used. We’re also introducing client credentials access to address a concern developers have raised: recovering backend access when a refresh token is lost.

A new option for backend recovery

With client credentials access, your backend can request a fresh, short-lived access token using a request signed with your app’s private key. This flow doesn’t require a refresh token or a merchant to reopen your app, so it provides a way to regain access after losing a refresh token during an outage or database restore.

Your app must still be installed on the store, and access remains limited to the scopes granted to that installation. You’ll need to configure the signing key and implement this flow in your backend.

Enforcement schedule

The enforcement timeline has been updated with incremental penalties for non-compliant apps:

  • January 1, 2027: Non-compliant apps are delisted from the Shopify App Store and blocked from new installs. Existing installations can continue making affected API requests.

  • January 15, 2027: Merchants using non-compliant apps see warnings in Shopify admin about the risk of service interruption and the action they can take.

  • April 1, 2027: Affected Admin API requests using non-expiring offline access tokens return HTTP 403. Workflows that depend on those requests will be interrupted.

Complete migration before January 1 to avoid distribution.

What you need to do

Follow the migration guide to request expiring tokens and migrate existing installations. The direct migration flow runs from your backend without requiring merchants to reopen or reinstall your app.

Store the returned token pair and expiry information, test refresh and recovery handling, and verify that background jobs continue working before rolling out across your installed stores. Client credentials access is an additional option for backend token acquisition; it doesn’t configure recovery automatically.

Who’s affected

This schedule applies to all existing public apps. The requirement for public apps created on or after April 1, 2026 remains in effect. Custom apps, apps created by merchants, and online access tokens are not affected. Traffic to the Payments Apps API is exempt.

@TerenceShopify would be a good news if at least you listened to the community and gave us more time.


With the new application only access token - does issuing a new token invalidate other one(s) that were generated less than one hour ago?

Just a suggestion, is it possible to show the (or a list of) shop that is still using non-expiring offline access token, in the Shopify Dev dashboard?

I am pretty sure I have migrated all my apps (which include all the active stores using it) to expiring offline access token 3 weeks ago, but last week I have started seeing the warning “Deprecated offline token used” reappearing in the dashboard, I would like to be able to see which shops are still using the non-expiring offline access token

@TerenceShopify can you confirm that the application-only access token will also work with REST API calls? The documentation mentions only Gprahql.

The dashboard shows the warning if the app has used a non-expiring access token in the past 14 days. I’ll dm you to follow up on specific apps and shops.

Yes, the requirement applies to both GraphQL and REST Admin APIs.

@TerenceShopify Sorry if I wasn’t clear! I wasn’t asking about the requirement, but whether application-only access tokens can be used to make both GraphQL and REST Admin API calls. The documentation only mentions GraphQL. Could you confirm?

With the new application only access token — does issuing a new token invalidate other one(s) that were generated less than one hour ago?

No. With application-only access, acquiring a new token does not invalidate previously issued tokens. Each token remains valid until its own expiry unless separately revoked.

would be a good news if at least you listened to the community and gave us more time.

I understand the request for more time and the work this migration requires. Under the enforcement timeline announced today, existing installations can continue making affected Admin API requests through March 31, 2027. However, non-compliant public apps will be delisted from the Shopify App Store and blocked from new installs on January 1, and merchants using them will see warnings beginning January 15. Affected requests using non-expiring offline access tokens will return HTTP 403 beginning April 1.

Throughout this process, we’ve been listening to developers and merchants across the Shopify community - here on the community board, on social media, over email, during AMAs, and in video calls. Those conversations have highlighted both the challenges developers face with migration and the need to strengthen app security.

We’re continuing to improve the token flows, including the application-only access option announced today, while maintaining the expiry requirement. Merchants and buyers rely on Shopify to protect their data, and limiting how long a leaked access token can be used is one part of that responsibility.

Yes, both GraphQL and REST. We’ll fix the docs.

That’s a good news, thank you for confirming.

For the rest of your message, yes that’s what you said before, and being delisted is the same as having no extra-deadline. Nobody wants to get delisted.
I just meant to display my (our) frustration about it. We’re running complex apps, the migration is non-trivial, we’re washed out, trying to survive AI, there is black friday + end of the year stuff. Busy time.

Migrating to the new token system is at the bottom of the list, it’s going up to the top, only because Shopify decided not to be on our side for this.


I’m still grateful that you listened to us on the technical side @TerenceShopify - and more importantly that you answered before GTA6, otherwise we might have had to face a temporal paradox.

Thanks for the clarification, @TerenceShopify !

Sorry for all the follow-up questions, but I’ve received some additional feedback from my developers following today’s update. I think these clarifications could also be helpful to other developers in the community.

I have three questions about application-only access tokens:

  1. Legacy token compatibility: When we generate our first application-only access token for a shop, does it invalidate the existing legacy non-expiring offline token for this shop? Or can we continue using the legacy token until Shopify fully sunsets it, or until we perform the first refresh using the new refresh-token flow?

  2. Coexistence with refresh tokens: Can application-only access tokens and the new expiring offline access tokens (using the refresh token flow) safely coexist for the same shop? In other words, can both types of tokens remain valid and be used simultaneously for the same shop, or does generating one invalidate the other? For example, could we use expiring offline access tokens for live user sessions and application-only access tokens for background/backend operations?

  3. Long-term support: Is application-only access here to stay as a fully supported authentication method, or is it a temporary solution designed to make the migration easier?

Thanks again for your time and for answering all these questions!

I appreciate the honest and candid feedback. I know developers have a lot on their plate and Shopify putting toilsome requirements isn’t anybody’s idea of a good time. This particular change is important for app security as we’ve discussed.

The good news is that we’ve heard lots of feedback from developers who have dealt with the migration in a matter of hours with no problems. I know not all apps are equal and some are more complex than others, but we do see in the data that the migration is overall progressing well.

And for the record I too am looking forward to spending time with Jason and Lucia in November.

@TerenceShopify thank you for following up and answering the questions. That’s the what’s we’ve missed in the recent months and exactly why we’re all extremely frustrated.

You might not realize it but even your shortest follow ups help us to feel listened to, even if the outcome is not 100% the desired one. Kudo for that.

Legacy token compatibility: When we generate our first application-only access token for a shop, does it invalidate the existing legacy non-expiring offline token for this shop? Or can we continue using the legacy token until Shopify fully sunsets it, or until we perform the first refresh using the new refresh-token flow?

Acquiring an application-only access token does not itself invalidate the shop’s existing legacy non-expiring offline token. However, continued legacy-token use remains subject to the migration requirements and their API Health warnings, delisting, and other consequences. An app that still uses legacy tokens for affected API calls has not fully migrated.

Also note that once you exchange an older non-expiring token for a new expiring token the older token is invalidated.

Coexistence with refresh tokens: Can application-only access tokens and the new expiring offline access tokens (using the refresh token flow) safely coexist for the same shop? In other words, can both types of tokens remain valid and be used simultaneously for the same shop, or does generating one invalidate the other? For example, could we use expiring offline access tokens for live user sessions and application-only access tokens for background/backend operations?

Yes, application-only access tokens and expiring offline access tokens acquired through token exchange or authorization code flows can operate in parallel for the same app and shop. One clarification on your example: use online tokens for interactive requests that need to respect the signed-in staff member’s permissions. Expiring offline tokens still act with the app’s permissions.

Long-term support: Is application-only access here to stay as a fully supported authentication method, or is it a temporary solution designed to make the migration easier?

Application-only access is a supported, long-term authentication method. It is not a temporary migration solution.

i have updated my app