Action required: existing public apps must use expiring offline access tokens by January 1, 2027

Authentication & Access
1

We’re updating how public apps handle offline access tokens to better protect merchant data. By January 1, 2027, all public apps — including those created before April 1, 2026 — must use expiring offline access tokens when calling the Admin API. Public apps still using non-expiring tokens after that date will receive authentication errors.

This extends the April 1, 2026 change — which applied only to new public apps — to the full population of public apps. Custom apps and apps created by merchants are not affected.

Learn how expiring tokens differ from non-expiring tokens.

Why this change

Non-expiring tokens, if leaked, remain valid indefinitely. Expiring tokens close that window in 60 minutes and rotate automatically — dramatically reducing the impact of a credential leak. This aligns with modern OAuth practices, and as a developer it gives your app a predictable refresh flow.

What you need to do

Migrate each installed shop from a non-expiring offline token to an expiring one. Merchants don’t need to reinstall — your app exchanges existing tokens through code. Follow the migration guide for the step-by-step path.

If you use Shopify’s app templates and official API libraries, refresh handling is already implemented for you — you only need to handle the token exchange and storage updates.

FAQ

I saw the April 1, 2026 changelog. What’s different now? That change required new public apps to use expiring tokens. This change extends the same requirement to all public apps, including ones created before April 1, 2026. Same mechanism, broader scope.

How do I know if my app already uses expiring tokens? Check API Health in your app’s Dev Dashboard for per-app status, or look for expires_in in your token responses.

Will my merchants need to reinstall my app? No. The migration is server-side — your app exchanges existing tokens for expiring ones using your code. Merchants experience no disruption during migration.

What happens on January 1, 2027 if I haven’t migrated? Admin API calls made with non-expiring offline access tokens will receive authentication errors after that date. This affects any merchant using your app.

Does this affect Storefront API, Hydrogen, Flow, or Bulk Operations? No. This change is specific to the Admin API and offline access tokens for public apps.

Learn more

Have questions or hitting a snag? Reply in this thread.

3

Any chance we can have a transition period where both the old and new access tokens will work? These kind of changes make me nervous in case something goes wrong, so having the ability to test the expiring tokens while having a temporary fallback would be highly appreciated.

Additionally this will also help deal with any jobs that are queued to be processed and might still use the old token. Instead of having these fail, they work with the old tokens during the transition period.

4

I’m thinking the same thing as @Philo. January 1st, 2027 also sounds far away, but between now and then we still have BFCM, Christmas, and other high-traffic periods where pushing this kind of major production change is always a bit stressful, especially when managing multiple apps to migrate.

Having a transition period where both the old and new access tokens continue to work temporarily would really help reduce the risk and allow us to properly test everything in production before the previous tokens fully expire. I definitely think that kind of fallback period would make the migration process much smoother and safer for everyone.

5

This is effectively the period we’ve been in since we added support for token expiry last year. Apps can choose to acquire expiring access tokens by including expiring=1 during token acquisition. It’s valid for an app to have both expiring and non-expiring tokens. Apps do not need to make a full switch from one type to another in one go.

8

This is not what the docs imply. It seems that when you migrate to an expiring token the non-expiring one is immediately invalid.

Step 4: Migrate existing tokens

For installed shops with existing non-expiring tokens, perform the migration using token exchange. The migration can be done via a background job or during the next app launch.

Caution

The original non-expiring token will be revoked upon successful exchange. This migration is irreversible. To obtain a new non-expiring offline access token, the app would have to re-trigger the token acquisition flow with merchant interaction.

9

Correct, when you migrate a particular offline access token it will become invalid. However, you do not have to migrate all your stored access tokens at once. You can test out the migration with just one access token and validate that your app is working correctly.

10

Can you have a valid expiring token and a valid non-expiring token at the same time?

Heath

11

FYI. You don’t have to migrate the non-expiring token. You can save it in case you need to revert and have the user go through the process to create an expiring token. This allows for a revertable transition.

12

Can you have a valid expiring token and a valid non-expiring token at the same time?

Yes, it’s valid to have both at the same time for a given shop.

13

Hi, thanks for the update!

We currently maintain a payment extension and would like to confirm whether this change also applies to our use case or only to standard public apps directly using the Admin API. Specifically, should payment apps/extensions that interact with the Admin API using offline tokens plan to migrate to expiring tokens as well?

As an example, there is this mutation: paymentsAppConfigure - Payments Apps API

which is called using the authentication described here: Payments Apps API reference

and relies on the X-Shopify-Access-Token header. Would this flow also be impacted by the upcoming changes?

Any clarification would be greatly appreciated. Thanks in advance!

14

Hi Terrence,

Can you clarify your last statement please? it seems to contradict your previous statements:

Yes, it’s valid to have both at the same time for a given shop.

The above statement implies for a single shop we can have both an expiring and non expiring token.

yet, your previous statement and the DOCS suggest otherwise

Correct, when you migrate a particular offline access token it will become invalid.

Also, can you clarify if apps that predate ‘public apps’ require migration as these do not show the deprecated message on the dev dashboard, although they are publicly available and aren’t custom apps either.