Shopify Expiring Offline Access Tokens: What Every App Developer Needs to Know Before April 1, 2026

What's Actually Changing

Until now, offline access tokens in Shopify were non-expiring — once issued, they worked indefinitely. Starting April 1, tokens issued to new public apps will have a limited lifespan, requiring your app to implement a token refresh flow. This aligns Shopify with modern OAuth 2.0 practices used by platforms like Google and Stripe.

Who This Affects

Affected: Public apps created on or after April 1, 2026 that call the Admin API.

Not affected: Public apps created before April 1, 2026 (existing apps keep working), custom apps at any time, and apps created by merchants in the Dev Dashboard or Shopify admin.

Why Shopify Is Making This Change

The security case is straightforward: if an offline access token is ever leaked — from a breach, an exposed .env file, or a compromised CI/CD pipeline — a non-expiring token gives an attacker permanent access to a merchant's store. Expiring tokens limit that window significantly.

What You Need to Do

If you use Shopify's official app templates (Remix, Next.js): Good news — expiring offline tokens are already handled by @shopify/shopify-app-remix and @shopify/shopify-app-express. Just make sure you're on a recent version.

If you have a custom auth implementation: You'll need to: store the token AND its expiry timestamp from the OAuth response, check expiry before each API call, and initiate a refresh using your refresh token when expired.

async function getValidToken(shop) {
  const stored = await db.getToken(shop);
  
  // Refresh if expiring within 1 hour
  if (stored.expiresAt - Date.now() < 3600 * 1000) {
    const refreshed = await refreshShopifyToken(stored.refreshToken);
    await db.saveToken(shop, refreshed);
    return refreshed.accessToken;
  }
  
  return stored.accessToken;
}

Key detail: Build a middleware layer that proactively refreshes tokens before they expire (e.g., when < 1 hour remaining) rather than reacting to 401 errors. Proactive refresh prevents failed API calls from reaching your users.

Timeline

• March 20, 2026 — Shopify announced the change
• April 1, 2026 — Enforcement begins for all new public apps
• Existing apps — Not affected (no forced migration announced yet)

Bottom Line

If you're starting a new Shopify app build after April 1, factor token refresh into your auth architecture from day one. If you're using Shopify's official libraries, you're already covered. For existing apps, this is a good prompt to review your token handling — Shopify hasn't announced a forced migration deadline yet, but it's likely coming.

How I Would Audit This

Token changes should be handled like an app reliability project. I would audit how the app stores offline tokens, which shops are affected, what reinstall or reauthorization path exists, and what background jobs fail if a token is invalid.

• List all shops and token creation dates where available.
• Find every background job using offline access.
• Add explicit handling for invalid token errors.
• Prepare merchant messaging before jobs fail silently.
• Test reinstall and reauthorization paths on a development store.

Production Failure Modes

The worst app bug is silent sync failure. If an offline token expires or becomes invalid and the app keeps marking jobs as successful, the merchant discovers the issue through bad data.

• Catching all API errors as generic retryable failures.
• No shop-level auth health status.
• No alert when background jobs repeatedly fail auth.
• Merchant cannot self-reconnect.
• Webhook handlers assume token availability without checks.

Copy/Paste Starting Point

if (error?.status === 401 || error?.message?.includes("Invalid API key or access token")) {
  await markShopAuthRequired(shop);
  await notifyMerchantReconnect(shop);
  return;
}

The exact error handling depends on the Shopify client, but the app needs a first-class auth-required state rather than endless retries.

What I Would Ship First

I would ship auth health visibility first, then migration messaging. That gives support and merchants a clear path if a shop needs reconnecting.

• Add shop auth status.
• Stop retry storms on auth failures.
• Provide reconnect CTA.
• Alert on repeated 401s.
• Document the merchant-facing impact.

My Shopify review angle

When I would review this in a client Shopify store, I would start with the operational surface instead of the headline. Shopify Expiring Offline Access Tokens: What Every App Developer Needs to Know Before April 1, 2026 only becomes useful when the reader can map it to a theme file, app setting, Admin API job, checkout rule, or storefront behavior they can actually test.

I would not leave this as theory. I would apply it to one actual page, integration, bug, or client decision and keep the evidence beside the recommendation.

Pre-launch Shopify checks

• Check the exact Shopify surface before changing code.
• Test with products that have missing images, long variants, empty metafields, and unusual prices.
• Confirm the change is visible in server-rendered HTML where SEO/AEO matters.
• Keep a rollback path for app or theme changes.
• Write a handoff note so the merchant team knows what can be edited safely.

Edge cases in the store

• The article sounds correct but does not explain what to edit in Shopify.
• The guidance ignores app conflicts, API versions, or messy product data.
• The change helps desktop screenshots but hurts mobile checkout.
• The page makes a claim that is not backed by visible content or schema.

Merchant handoff block

Implementation check for Shopify Expiring Offline Access Tokens: What Every App Developer Needs to Know Before April 1, 2026:
1. Confirm the Shopify surface involved: theme, Admin API, checkout, app, or storefront.
2. Test with messy catalog data, not only a demo product.
3. Verify permissions, API version, and rollback path.
4. Record the production edge case this change protects.

A short review block like this is often enough to catch the gap between a nice idea and a safe production change.

Where I would add more proof

I would keep improving this page by replacing any remaining abstraction with artifacts from actual work: test output, screenshots, metrics, source references, or before/after notes.

For a shorter post, I would add depth through one tested example rather than filler. One good edge case or validation note is more useful than another generic overview.

• One real example from the workflow.
• One edge case that breaks the simple advice.
• One metric or signal to watch after the change.
• One clear action the reader can take today.