Hi there,
I would like to share an issue we are facing with the newly added requirements for Expiring offline tokens.
Background context
We have a few apps that existed before the change that don’t use expiring offline tokens. When running the apps locally, we create a new app on our partner portal so that devs can run the app before pushing changes to staging and production. Additionally, we have a service that manages API calls to the Billing API between the apps. Due to the need of testing billing, we have to select public distribution for the developer apps since it causes API errors when calling the Billing API when public distribution is not selected.
The issue we are facing
For newly created apps in the dev dashboard that are running our existing apps locally (which don’t have expiring offline token logic implemented) the API keeps returning the following:
[API] Non-expiring access tokens are no longer accepted for the Admin API. Start using expiring offline tokens: https://shopify.dev/changelog/expiring-offline-access-tokens-required-for-public-apps-april-1-2026
Is it possible to move this gate to the app submission step rather than blocking it in the API? We have no intention of submitting our dev apps at any point and this is causing us major issues in our app development process whenever we have a need to create new apps on the partner portal for development purposes.
I appreciate that this is creating some issues for your dev process. The enforcement of expiring tokens happens when requests are made to the Admin API. It’s not a one-time check during the app store review process. By enforcing during API requests it allows us to ensure that apps are meeting the requirements even after they’ve made it through app Store review.
Are you using a Shopify app template for your apps? All of our app templates and libraries use expiring tokens by default and have for several months.
It’s a mixed bag when it comes to templates used since we have apps that are 10+ years old that don’t utilize official libraries while some others do. And not all libraries support it, example being shopify-api-php which doesn’t have support for expiring offline tokens and this library is used by quite a lot of our apps (I am aware that there is a new experimental php library that does have support for expiring offline tokens but we are reluctant when it comes to using it while it’s still fresh and experimental).
The frustrating part here is how this has been communicated and how it’s being enforced. We tend to get a heads up about changes that require actions on our side roughly a year in advance. Expiring offline tokens were released in December 2025 and the announcement for mandatory usage was made on March 20th 2026, 11 days before it’s being enforced.
In a addition to that, the wording of the changelog, while technically true of what is happening now is a bit ambiguous.
Expiring offline access tokens required for new public apps as of April 1, 2026
When I read it, my colleagues and I interpreted it as new public apps that are submitted and released on the Shopify App store and not when distribution is selected since we’ve never seen nor expected this type of API behavior before.
We have a temporary workaround for now since we have a few apps on the partners portal that were created before April 1st that are no longer being used which will buy us some time to introduce these changes but we would really appreciate clearer communication and being given more time before newly introduced features are enforced in this way so that we can plan out these changes without being rushed/forced to make them on a short notice.
I appreciate that this change is frustrating and that the timeline was shorter than most of our API changes. One area of making changes to our APIs where we sometimes take a more aggressive timeline is on merchant and buyer data protection and that’s the underlying reason we made this change on a more aggressive timeline. I know that’s probably cold comfort for your team but I want to give you an honest answer as to why this change was made.