Shopify Expiring Offline Tokens: Jan 1, 2027 Deadline

Shopify just put a hard deadline on a credential class most app developers forgot they were running. Starting January 1, 2027, every public app calling the Admin API must use expiring offline access tokens. After that date, public apps still using non-expiring tokens get authentication errors. Not warnings. Errors.

This extends the April 1, 2026 rule that only applied to newly created public apps. Now it covers all public apps, including the ones built years ago that have been quietly running on a permanent token nobody has touched since install.

If you run a public Shopify app, or you've built companion apps for Hydrogen storefronts that talk to the Admin API in the background, this is on your roadmap whether you've scheduled it or not. Here's the migration, the architecture, and the parts that bite if you leave it to December.

What's actually changing

The change is narrow and specific, which is the good news.

1. Offline tokens are getting an expiry and a refresh flow

Offline access tokens are the default access mode for the Admin API. They're meant for service-to-service work: background jobs, webhook responses, scheduled maintenance, anything that runs without a merchant sitting in the browser. Historically they were non-expiring. You did the OAuth dance once at install, stored the token, and used it forever.

As of December 2025, Shopify supports expiring offline tokens. They behave the same for background work, but they rotate. Each token has a finite life, and you get a refresh token to mint the next one without the merchant being involved.

2. The refresh token has a 90-day lifetime

The mechanics: when your app obtains an expiring offline token, Shopify returns a refresh token alongside it. The refresh token has a 90-day lifetime. Your app uses it to get a new access token before the old one dies, with no merchant interaction. This is the standard OAuth refresh pattern, finally applied to Shopify's offline tokens.

3. One refreshable token per app and store

Important operational detail. When your app obtains a new expiring offline token, Shopify retires older expiring offline tokens for the same app and store. The retired access token stays valid until its expires_in duration ends, so in-flight requests complete cleanly. But the retired token's refresh token is invalidated immediately. You can't use an old refresh token to extend an old access token's life. One live refreshable token per app per store. Design your storage around that.

4. The deadline structure

April 1, 2026 already required expiring tokens for newly created public apps. January 1, 2027 extends that to every public app, including apps created before April 1, 2026. After January 1, public apps still presenting non-expiring tokens to the Admin API receive authentication errors.

What's affected and what isn't

Worth being precise here, because the blast radius is narrower than the headline suggests.

Affected: Public apps making Admin API requests with non-expiring offline access tokens, including apps created before April 1, 2026. If your app is listed in the Shopify App Store or distributed publicly, and it calls the Admin GraphQL or REST API on a background token, you're in scope.

Not affected: Custom apps. Apps created by merchants directly in the Dev Dashboard or in the admin. If your Hydrogen build uses a custom app for its Admin API access (which many do), that specific token isn't subject to this deadline. But read the next section before you relax.

Why this matters for Hydrogen teams specifically

Hydrogen storefronts mostly talk to the Storefront API, not the Admin API, so the reflex is to assume this doesn't apply. That reflex is half right and half dangerous.

Your storefront is probably fine. Your companion apps probably aren't. A real Hydrogen build rarely ships as just a storefront. There's usually a constellation of supporting services: a subscription manager, an inventory sync, a custom ERP bridge, a reviews importer, a metafield seeder, a webhook processor that reacts to order events. Each of those that calls the Admin API holds an offline token. If any of them is packaged as a public app, the deadline applies. Most teams have never inventoried which of their supporting services are public apps versus custom apps versus raw scripts.

Background jobs are the highest-risk surface. The whole point of offline tokens is unattended background work. That's also where a token failure is least visible. A storefront auth failure throws an error a customer sees in seconds. A background sync job failing to authenticate at 3am on January 1 fails silently, queues up, and surfaces as "why is inventory wrong" three days later. The jobs most affected by this change are exactly the ones nobody is watching on a holiday weekend.

The refresh flow is new code, not a config flip. Migrating isn't toggling a setting. You have to implement the refresh logic: detect token expiry, present the refresh token, store the new access token and the new refresh token, retire the old one, and handle the failure case where the refresh token itself has expired past 90 days and you need a fresh OAuth grant. That's a real chunk of authentication code, and authentication code is exactly where you don't want to be moving fast in late December.

Custom apps dodge the deadline but not the principle. If your Hydrogen build runs on a custom app token, you're not forced to migrate by January 1. But non-expiring tokens are non-expiring liabilities. A leaked permanent token is valid until someone notices and revokes it. A leaked expiring token is dead in 90 days at the outside. The security argument that drove this change applies to your custom app too, even though the deadline doesn't.

The migration, in order

What to actually do, sequenced so you can start today:

1. Inventory every offline token you hold

List every service in your stack that calls the Shopify Admin API. For each, record: is it a public app, a custom app, or a raw script? Is the token expiring or non-expiring? When was it last rotated? Most teams discover at this step that they have more Admin API integrations than they remembered, and at least one running on a token created during an install nobody documented.

2. Flag every public app on a non-expiring token

Those are your January 1 deadline items. Everything else is lower priority. Sort ruthlessly. A public app with a non-expiring token is a hard deadline. A custom app with a non-expiring token is a should-fix, not a must-fix.

3. Implement the refresh flow in a library, once

Don't scatter refresh logic across five services. Write one token-refresh module that handles obtaining, storing, refreshing, and retiring expiring offline tokens, with the 90-day refresh-token window baked in. Every service that calls the Admin API imports it. This is also the right place to add logging so that a refresh failure pages someone instead of failing silently.

4. Test the failure case explicitly

The path everyone forgets: the refresh token expired past 90 days because the app was idle, and now you need a full OAuth re-grant with the merchant. Test it. Simulate an expired refresh token and confirm your app degrades gracefully into a re-auth prompt instead of throwing a raw error at a background job. This is the case that will actually break in production if you don't handle it.

5. Migrate the highest-traffic public apps first

Roll the refresh flow out to your busiest public apps first, where you'll catch edge cases fastest under real load. Then sweep the long tail. Aim to be done by November, not December, so you have a buffer month before the deadline for whatever you didn't anticipate.

6. Add a deadline marker and a post-migration verification

Set a calendar item for early December to verify zero non-expiring public-app tokens remain in your stack. The cost of being wrong is authentication errors on New Year's Day, which is the single worst day of the year to debug an auth flow.

Where this fits in the bigger picture

This is the fourth credential-and-tooling tightening Shopify has shipped in roughly two months. Shopify CLI 4.0 removed the deprecated --force flag and forced SemVer discipline. App Automation Tokens moved CLI credentials to per-app scoping with forced expiration. Managed Payment Methods reshaped checkout-level configuration. Now offline access tokens get expiry and rotation.

The pattern is unmistakable. Shopify is systematically replacing permanent, broadly scoped, manually managed credentials with scoped, expiring, automatically rotated ones across every surface a developer touches. CLI auth, app deploy tokens, payment configuration, and now Admin API offline tokens.

The teams that run serious Hydrogen storefronts in 2026 increasingly look like small platform-engineering teams: pinned tool versions, locked-down CI/CD, per-app scoped credentials, scheduled rotation, and refresh flows that handle their own failure cases. Each of these is a small operational discipline. Stacked, they're the difference between a Shopify integration that runs itself and one that throws auth errors at 3am on a holiday.

The bottom line

January 1, 2027 is a hard deadline with a binary outcome: expiring tokens work, non-expiring tokens get auth errors. The migration is real engineering work, concentrated in background jobs that fail invisibly, which is the worst combination of "must do" and "easy to forget." Public apps are in scope. Custom apps aren't, but should migrate anyway on the same security logic. Inventory your tokens this month, implement the refresh flow once in a shared library, test the expired-refresh-token failure case explicitly, and be done by November.

If your team runs public Shopify apps or Hydrogen companion services on Admin API tokens and the offline-token migration is one more thing the roadmap can't absorb before year-end, the Weaverse team takes on Shopify and Hydrogen engagements end-to-end, including authentication refactors, token-rotation architecture, and background-job hardening. Senior engineers, fast scoping, deep fluency on the moving Shopify credential and API landscape. Talk to us →