Shopify App Tokens: Master Online vs. Offline Access for Smooth Integrations

Hey everyone,

It’s always fascinating to dive into the nitty-gritty discussions happening in the Shopify Community. Recently, I stumbled upon a thread started by @NicholasByDesign that really struck a chord, especially for those of you building custom Shopify apps or wrestling with complex integrations. The core challenge? How to properly manage Shopify’s API access tokens, specifically the difference between useOnlineTokens: true and offline tokens, and how to use them effectively.

Nicholas had built an admin app that relied heavily on useOnlineTokens: true. This is great because it gives you access to the associated_user object, which is super useful for knowing exactly which admin user is interacting with your app. But, as often happens, requirements evolve. He then needed to integrate third-party services that required the app's offline token. This is where the head-scratching began: how do you switch between these two token types at runtime, especially when your shopify.server.js configuration seems so… static?

The Token Conundrum: Online vs. Offline

Let's quickly recap what we're talking about. When you’re building a Shopify app, you deal with different types of access tokens:

  • Online Tokens: These are tied to a specific admin user's session. They’re short-lived and expire when the user logs out or their session ends. Crucially, they provide the associated_user object, which is why Nicholas found them so valuable for his admin UI.
  • Offline Tokens: These are long-lived and not tied to any specific user session. They’re perfect for background tasks like webhooks, cron jobs, or integrations with third-party services that need to operate even when no user is actively logged into the Shopify admin.

Nicholas's struggle was a common one: the Shopify documentation, at first glance, seems to suggest it's an either/or situation. You set useOnlineTokens to true or false during your app's initialization, and that's it. He was trying to find a "boolean solution to trigger a reload for useOnlineTokens true/false" based on whether an access token already existed in storage, and was hitting a wall due to the static nature of shopify.server.js.

The Expert Insight: It's Not About Toggling the App, It's About Toggling the Token

This is where the community really shone, with @oscprofessional providing the definitive answer. The core takeaway, which is super important for anyone in this situation, is this:

You cannot toggle useOnlineTokens at runtime; it’s static by design in Shopify.

Trying to re-initialize your app to switch between online and offline token modes is simply not the supported or scalable approach. Instead, the solution lies in a more nuanced strategy: managing which token you use per request, rather than reconfiguring your entire app.

Here's the scalable approach, straight from the experts:

  1. Initialize Your App Once (useOnlineTokens: true): When you first set up your Shopify app, configure it to request online tokens (i.e., useOnlineTokens: true). This is essential because it allows you to capture both the online and offline tokens during the installation or re-authorization flow.
  2. Capture and Store the Offline Token: This is a critical step. During the app installation or re-authorization process, make sure you capture the offline access token. This token needs to be stored persistently. Nicholas mentioned he was looking into MongoDB, which is an excellent choice for this. A database is key here, as you can’t rely on transient storage like cookies for long-lived offline tokens.
  3. Use Online Tokens for Admin UI & associated_user: Whenever an admin user is actively interacting with your app's UI within the Shopify admin, you should use the online token. This is where you'll get that valuable associated_user object, allowing you to personalize experiences or log actions to specific administrators.
  4. Use Offline Tokens for Background Services: For anything that doesn't involve a live admin session – think webhooks, cron jobs, background data syncing, or integrations with those third-party services Nicholas was talking about – you'll use the stored offline token. This ensures your app can perform its duties reliably without an active user session.
  5. Choose Your Token Per Request, Not Per App Configuration: This is the golden rule. Your app isn't toggling its configuration; it's dynamically deciding which token to use for each specific API call based on the context of that call. If it's an admin UI action, grab the online token from the current session. If it's a background task, retrieve the offline token from your database.

Putting it into Practice

Let's break down how this might look in a simplified workflow:

Imagine your app has an incoming request. First, you determine the context:

  • Is this an authenticated request from the Shopify admin UI? If yes, you'll likely have an active session with an online token available. Use that token for your API calls, which will give you access to the associated_user.
  • Is this a webhook, a scheduled job, or an internal service call? If so, there's no active user session. You would fetch the offline token that you previously stored in your database (e.g., MongoDB) and use it for your Shopify API interactions.

This approach gives you the best of both worlds: the immediate context of an active user when needed, and the persistent, reliable access for background operations. It avoids the headaches of trying to re-initialize an app that isn't designed for runtime toggling and keeps your integrations robust and scalable.

So, if you've been finding yourself in Nicholas's shoes, pulling your hair out trying to force a static configuration to be dynamic, remember this key insight from the community. Focus on intelligent token management at the request level, store those offline tokens securely, and you’ll find your Shopify app development a much smoother ride. This isn't just a workaround; it's the supported and most efficient way to handle tokens in a modern Shopify app.

Share:

Use cases

Explore use cases

Agencies, store owners, enterprise — find the migration path that fits.

Explore use cases