Shopify's 2027 Offline Token Deadline: Which Apps Must Migrate?

Reviewed 3 November 2026. If you own a public Shopify app that still uses non-expiring offline access tokens for Admin API requests, plan a migration before 1 January 2027. It is not a requirement for every Shopify shop, theme, custom app, or user-session token. Shopify's 27 October 2026 announcement introduced staged enforcement: App Store delisting and blocked new installs on 1 January for non-compliant existing public apps, merchant warnings from 15 January, and affected Admin API requests returning HTTP 403 from 1 April. Existing installs are not promised indefinite access. Shopify's dated announcement.

This guide gives app maintainers and the teams relying on those apps a scope decision tree and a testable migration checklist. It synthesizes official documentation; NxFold has not tested a merchant's production tokens, audited a particular client app, or measured demand for this topic.

First, does the deadline apply to you?#

These scope distinctions come from Shopify's 27 October update and access-token reference. A store owner should ask the app's developer for its compliance status, not copy OAuth code into a storefront.

The dates, and a documentation mismatch worth knowing#

Deadline verification (3 November 2026): Shopify's 27 October announcement, 30 October staff FAQ, and current migration guide now align on these stages: 1 January for delisting and blocked new installs, 15 January for merchant warnings, and 1 April for rejecting affected legacy-token API requests. Earlier versions of migration guidance used a different rejection date; do not repeat that superseded conflict as current. The staff FAQ covers GraphQL and REST Admin API usage, while the migration guide focuses on GraphQL; inspect your actual API requests. Shopify says warnings can reflect legacy-token usage in the preceding 14 days, so check background workers and delayed jobs if an alert persists after migration. Complete and validate migration before 1 January, not during the grace period. These are official platform milestones, not a tested NxFold implementation.

What actually changes in the credentials?#

An offline access token lets a public app work outside an individual staff session—for example, an order-sync worker or a webhook consumer calling the Admin API. A non-expiring token can remain usable until revoked or uninstalled. An expiring offline access token instead comes with an access-token lifetime and a refresh token. Shopify currently documents an access-token lifetime of one hour and a newly issued refresh token of 90 days; read the actual expires_in and refresh_token_expires_in response values rather than hard-coding these figures. Each refresh supplies a new access/refresh pair. Access-token reference.

Store credentials encrypted and tenant-scoped. The operational requirement is to write both replacement tokens and their expiry metadata together before treating a refresh as complete. Serialize refreshes per shop so two workers do not race and persist different generations. Shopify's 28 August refresh-resilience change provides a recovery path for a lost response; it is not a reason to keep old refresh tokens as the normal method.

Choose the migration path your code actually uses#

App built with Shopify's React Router or Remix template. Check that the version and session storage you deploy support expiring tokens. Shopify documents future: { expiringOfflineAccessTokens: true } in shopifyApp() and says its template handles subsequent token storage and refresh. A code flag alone is not a verification that every previously installed shop was migrated. Template instructions.

Custom token-exchange implementation. In the relevant token exchange, Shopify documents requesting expiring credentials with expiring=1. Persist access_token, refresh_token, expires_in, and refresh_token_expires_in. Implement serialized refresh and retry/re-authentication according to the documented error flow. Do not log tokens or paste them into diagnostics.

Authorization-code OAuth implementation. Shopify also documents expiring=1 on the code-to-access-token exchange. Verify you handle the refresh pair for each installation and recover from a token that is invalid or expired.

Inactive installations and background-only apps. Waiting for a merchant to open the app may leave shops unmigrated. Shopify provides a direct migration exchange that uses an active old non-expiring offline token plus app credentials, without a user session. This exchange invalidates the old token for GraphQL Admin API access. Confirm durable secure storage and an emergency recovery route before migrating a large set of stores. Its documented lost-response recovery is conditional, not a generic safe retry of every authorization request. Detailed migration procedure.

A separate client-credentials option announced on 27 October can help eligible backends regain access using a signed private-key assertion. It is an additional eligible authentication path, not proof that an existing refresh architecture was migrated. Shopify security update.

Practical rollout worksheet: test the failure cases, not just installation#

Use an authorized test shop and redacted logs; mark PASS / FAIL / NOT TESTED and record a responsible owner. The scenarios below are a proposed QA framework, not an account of NxFold carrying out these tests.

For the direct migration, Shopify documents particular invalid_subject_token and invalid_requested_token_type failures when the source credential or parameters are ineligible. A refresh-token failure may return 401 with invalid_request. Check the specific message and grant; do not treat error status alone as a complete diagnosis. Migration errors and recovery.

A small example of the decision, not a claimed implementation#

Hypothetical: An app synchronizes inventory for 12 installed merchants. It uses an old non-expiring offline token for each store. The team enables expiring token acquisition for new visits, but only 7 merchants open the app during the test period. The other 5 installations still need a documented migration path. The correct next step is to inventory the 5 outstanding shops, stage a safe backend exchange or merchant-assisted reauthentication if necessary, then verify background sync after refresh. The numbers here only illustrate a gap; they are not data from Shopify or a NxFold client.

An owner-ready record could contain: affected installation count, migration path, credential-storage version, last verified refresh, background-job check, exception owner, and the dated validation result. It should never contain raw tokens.

What to do this week#

If you maintain an affected public app, assign one technical owner, confirm the distribution and actual token type, test the new token-acquisition path and storage, and stage an existing-installation migration. Give yourself a rollback plan for application code and a reauthentication plan for credentials—do not assume you can reverse an already-exchanged token. Monitor Shopify's updated release notices before the January deadline.

If you only run a merchant store, ask each important third-party app developer whether its public-app offline token migration is complete and how interruptions will be handled. You do not need to implement OAuth in the store theme. For a different Shopify decision, see NxFold's Shop MCP shopping-agent guide or the ecommerce platform selection guide. Neither is a substitute for a public-app authentication audit.

Methodology: primary Shopify announcements dated 27 October 2026, the current official migration and token references, and a transparent hypothetical worksheet. No merchant token was accessed, no customer data was used, and no migration or compliance outcome is claimed.