Shopify now requires expiring offline access tokens for all new public apps as of April 1
Partner organizations must use role-based access control for all account management
The --force flag in Shopify CLI deploy and release is deprecated, use --allow-updates instead
Checkout metafield access through checkout.liquid is officially removed
Existing apps get a grace period but should migrate now before enforcement expands
Shopify shipped three breaking API changes in the 2026-04 release. If you build apps, themes, or custom integrations for Shopify stores, at least one of these affects you. Here is what changed, what breaks, and how to fix it before your code stops working.
Expiring Tokens Are Now Mandatory
Starting April 1, 2026, every new public app submitted to the Shopify App Store must use expiring offline access tokens. This is the biggest change in the batch. Previously, offline access tokens lived forever. You generated one during the OAuth handshake and stored it in your database. It worked until the merchant uninstalled your app. No rotation, no refresh, no expiration.
That era is over for new apps. Expiring tokens have a limited lifespan. When they expire, your app must use a refresh token to get a new access token. If your token handler is a simple "store once, use forever" pattern, it will break.
The migration path depends on your stack. If you are using the official Shopify Node.js library (@shopify/shopify-api), token refresh is already built in. Enable it in your session storage configuration. If you built a custom OAuth flow, you need to add refresh logic: detect expired tokens, call the token refresh endpoint, store the new token pair, and retry the original request.
Webhook handlers need special attention. When a webhook fires and your app processes it by calling back to the Shopify API, the access token might have expired between when you received the webhook and when you try to use it. The fix is straightforward: check token validity before making API calls, refresh if needed, then proceed. But if your webhook handler assumes tokens are always valid, it will start failing silently.
Existing public apps created before April 1 are not required to migrate yet. But Shopify has a track record of expanding these requirements. I expect existing apps will face the same mandate within 6-12 months. Migrating now while you have time is smarter than scrambling when the deadline hits.
Custom apps (created in the store admin, not the Partner Dashboard) are on a separate timeline. Shopify deprecated the old custom app creation flow in early 2026, pushing developers toward the app development dashboard. If you still have custom apps using legacy non-expiring tokens, those tokens continue to work for now. But the writing is on the wall. Every security-sensitive API change Shopify makes follows the same pattern: mandate for new apps first, then extend to existing apps 6-12 months later.
The token refresh flow adds one more failure point to your app. Network issues during refresh, race conditions when multiple webhook handlers try to refresh simultaneously, database locks on the token storage row. Test your refresh logic under load before it matters. I have seen apps that worked perfectly in development crash in production because two concurrent webhooks both tried to refresh the same token at the same time, and the second one invalidated the first one's result.
The security reasoning is sound. A leaked token that never expires is a permanent vulnerability. A leaked token that expires in 24 hours limits the blast radius. If you have ever dealt with a compromised API key, you know the difference between "revoke one key" and "figure out how many requests were made with this key over the past three years."
RBAC for Partner Organizations
Shopify rolled out role-based access control for all partner organizations. This is the biggest change to partner account management in years. Previously, partner accounts were either "owner" or "staff" with broad permissions. Now there are granular roles that control who can do what.
The practical impact hits agencies and teams hardest. If you have contractors, freelancers, or junior developers in your Shopify Partner Dashboard, their access is now governed by roles. Someone who only needs to manage theme files should not have access to billing information or app credentials.
For solo developers, this changes less day to day. But if you use API keys generated through the Partner Dashboard, verify that your account role has the permissions those keys need. A role change by an org owner could silently break your API access.
The enforcement is immediate. Shopify is not waiting for a migration period on RBAC. If your organization has not configured roles, the default assignments might not match what your team actually needs. Review them now.
One thing to watch: API keys generated by users with restricted roles may have narrower scopes than you expect. If your app was set up by an org owner and a staff member later rotates the key under their restricted role, the new key might lack permissions the app needs. Test API access after any role or key changes in your partner org.
CLI Flag Deprecation
The --force flag on shopify app deploy and shopify app release is being removed. If your CI/CD pipeline uses --force, it will break when the flag is fully deprecated (expected May 2026).
The replacement is --allow-updates. It does essentially the same thing (permits overwriting existing configurations during deployment) but with a name that better reflects its behavior. A find-and-replace in your deployment scripts fixes this.
Check these places for the old flag: GitHub Actions workflow files, Bitbucket pipeline configs, Jenkins build scripts, Makefile targets, and any shell scripts that automate Shopify deployments. One missed instance means a failed deploy the next time the pipeline runs.
For teams using the Shopify CLI interactively (not in CI/CD), the change is transparent. The CLI will warn you about the deprecated flag before it stops accepting it entirely. But automated pipelines do not read warnings. They just fail.
While you are updating CI scripts, also check which version of the Shopify CLI your pipeline installs. If it pins an old version, you might avoid the deprecation temporarily but miss security patches and new features. Pin to a recent minor version and update quarterly.
Checkout Metafield Deprecation
The third breaking change removes checkout metafield access through the legacy checkout.liquid template. If you are still using checkout.liquid for custom checkout experiences, this is another reason to migrate to Checkout Extensibility.
Shopify has been pushing merchants and developers toward Checkout Extensibility (checkout UI extensions and Checkout Branding API) since 2024. The checkout.liquid approach was always a Shopify Plus exclusive that gave full HTML/CSS/JS control over the checkout page. The trade-off was that it could not benefit from Shopify's ongoing checkout optimization, security patches, and new features like Shop Pay improvements.
If your app reads or writes checkout metafields through checkout.liquid, you need to switch to the Checkout Extensibility APIs. The metafield data itself is not going away. Only the access path through checkout.liquid is being removed.
For most developers, this is a non-issue. checkout.liquid usage has been declining since Shopify started gating it behind Plus plans and actively discouraging it. But if you maintain legacy Plus stores with custom checkout code, audit those templates now.
The Bottom Line
Three breaking changes in one release cycle: mandatory expiring tokens for new apps, RBAC enforcement for partner orgs, and CLI flag deprecation. Plus the ongoing checkout.liquid sunset.
The common thread is security. Expiring tokens limit credential leak damage. RBAC prevents permission creep. Even the CLI flag change moves developers toward safer deployment patterns.
If you build on Shopify, block out an hour this week to audit your token handling, check your partner org roles, and search your CI scripts for --force. The migration effort is small. The cost of ignoring it is a production outage when your token expires or your deploy script fails at the worst possible time.
I updated my own Shopify integrations the day these changes dropped. Token refresh took about 30 minutes to implement and test. The CI flag swap was a one-line change. RBAC review took five minutes since I am the only person in my partner org. Total time: under an hour. That is a cheap insurance policy against a broken deploy pipeline or a silent API failure during a product launch.
Shopify publishes these changes on their developer changelog at shopify.dev/changelog. Bookmark it. The April release had three breaking changes. The May release will likely have more as the --force flag reaches full deprecation. Staying ahead of these changes is less work than debugging them after they break production.
Top comments (0)