Shopify's expiring offline access tokens and its new IP allowlist answer the same question from two sides: what happens when an app's Admin API token leaks. On October 27, 2026, Shopify confirmed that every public app must move to expiring offline tokens by January 1, 2027, and shipped three opt in controls alongside the deadline. The deadline only binds public apps. The controls are open to everyone, and for a merchant running custom integrations they are the more useful half of the announcement.
What Shopify changed on October 27
Shopify kept the January 1, 2027 migration deadline for expiring offline tokens and added a staged penalty for public apps that miss it. The October 2026 app security update sets out three dates. On January 1, 2027 a non compliant app is delisted from the App Store and blocked from new installs, while existing installs keep working. From January 15, merchants using it see a warning in their admin. From April 1, 2027, Admin API calls made with a non expiring offline token return HTTP 403.
Shopify is explicit that the later dates exist so merchants can prepare, not as extra runway for developers. Apps created on or after April 1, 2026 were already held to the new rule. Custom apps, merchant created apps and online tokens are excluded.
The same release added client credentials recovery, an IP allowlist for Admin API tokens in the Dev Dashboard, a new [network_access] section in shopify.app.toml, and identity checks before an app is installed on development or client transfer stores.
Expiring offline tokens vs IP allowlist: what each one stops
An expiring token limits how long a stolen credential works, while an IP allowlist limits where it works, and the two cover different failure modes. Per the offline access token documentation, an expiring offline token lives for one hour. Its refresh token lasts up to 90 days, rotates on every use, and stops working 30 days after it was first used to refresh. A token copied out of a log file or a leaked environment dump is worthless within the hour. A refresh token that leaks is still dangerous, which is why rotation matters: once the real app refreshes, the stolen copy dies.
The IP allowlist works on a different axis. You enter the IPs or CIDR blocks your backend calls from, dry run the list against the last few days of requests, then switch enforcement on. From then on, GraphQL and REST Admin API calls from any other address fail with a 403, even when the token is valid. A leaked token, expiring or not, becomes useless outside your network.
Our ranking is simple. For an app with static egress, the allowlist is the stronger control, because it neutralises a leak instantly rather than after an hour. Expiring tokens are the floor Shopify can enforce across thousands of apps, since many of them run on hosting where a fixed IP is not available. Shopify notes that allowlist support for serverless platforms with dynamic addresses is still coming, so today it fits apps on containers, VMs or behind a NAT gateway.
Why custom apps should still adopt both
Custom apps are exempt from the token deadline, but they usually hold the broadest scopes on the store, so they have the most to lose from a leak. A typical Shopify Plus build carries an ERP connector, a PIM sync, a fulfilment bridge and a reporting job, each with a long lived offline token and write access to orders, products or customers. Those tokens tend to live in CI secrets, shared password vaults and the laptop of whoever set them up two years ago.
None of that changes on January 1. That is exactly the problem. The exemption keeps custom apps working, but it does not make them safer, and the merchant carries the risk directly because there is no app vendor between them and the incident. When we build integrations and back office automation for Shopify Plus storefronts, these middleware services almost always run from a fixed egress address. That makes them ideal candidates for the allowlist, today, with no code change.
Moving a custom app to expiring tokens is more work, since every job that calls the Admin API needs refresh handling and safe concurrent token storage. It is still worth planning. The deadline exemption may not last, and the refresh logic is the same code you will need for any public app you ship later.
Client credentials and network_access in one paragraph each
Client credentials recovery lets a backend get a fresh token without a merchant reopening the app, which removes the main operational objection to expiring tokens. The backend signs a request with the app's private key and receives a short lived token, valid for up to one hour for publicly distributed apps, with no refresh token attached. If a refresh token is lost in a failed deploy or a database restore, the app recovers on its own instead of silently stopping its sync jobs.
The [network_access] section is about the storefront rather than the Admin API. Per the network access changelog, allowed_sources lists up to 20 HTTPS origins that your extensions and app pages load from or call, and allowed_navigation_hosts lists up to 20 hosts that customers can be linked to without the leave store warning. Shopify uses the first list to spot requests your app did not make, which is useful signal if a third party script in a theme starts impersonating your extension.
What we would do before January 1
Inventory every Admin API token on the store first, then decide control by control, because the right answer differs for public and custom apps.
For public apps you build or maintain, finish the expiring token migration in November and run the refresh path under load before the holiday freeze. Add client credentials recovery so a lost refresh token never needs a merchant to act. Add the [network_access] section in the same release and run shopify app security check, which we covered in our post on the app security check scan vs agent split.
For custom apps and middleware, turn on the IP allowlist this month for anything with a fixed egress address. Start in test mode against recent traffic, because a forgotten cron host or a developer machine calling production will show up there before it shows up as a 403. Then put expiring tokens on the roadmap for the integrations with write scopes on orders and customers.
For merchants, ask every vendor whose app is installed on the store whether it has migrated. An app that has not done it by December will start showing warnings in January and stop working on April 1, and replacing an ERP or loyalty connector in the first quarter is a project nobody wants to start in a hurry.