Shopify Custom Apps After the 2026 Dev Dashboard Change: What Actually Broke

On 1 January 2026, Shopify closed the flow that most merchants used to connect their store to an outside system. You can no longer create a custom app from Settings → Apps and sales channels → Develop apps. New custom apps must now be built in the Dev Dashboard and then installed on the store. Existing custom apps are not affected and keep working.

A custom app is an app built for one store or one merchant’s set of stores. It is not listed on the Shopify App Store. It exists to do one job for one business — push orders into an ERP, sync stock from a warehouse system, run pricing logic that no public app handles. “Private app” is the old name. Shopify deprecated private apps in January 2022 and converted the remaining ones to custom apps in 2023.

Before: A merchant or developer opened the Shopify admin, created a custom app, ticked the API scopes, installed it, and revealed a permanent Admin API access token. That token went into a config file and worked forever. Now: Apps are created in the Dev Dashboard (dev.shopify.com/dashboard) or through the Shopify CLI. The app is configured as a version, released, then installed on the store. Authentication runs through OAuth.

Not changed: Every custom app created before 1 January 2026 continues to run. You do not need to migrate it. You do not need to recreate it. Its token still works. Shopify’s stated reasons are security, clearer permission scopes, better lifecycle management, and one consistent development workflow across the ecosystem.

The old admin flow handed you a permanent Admin API access token, revealed once. Teams pasted it into an environment variable and forgot about it for three years. The Dev Dashboard flow does not work that way. Tokens now last 24 hours and must be refreshed in code.

For an app you are building for your own store, use the client credentials grant: take the Client ID and Client secret from the app’s Settings tab, request a token from Shopify’s OAuth endpoint, and request a new one when the old one expires. A middleware script written in 2021 that reads one static token from a .env file will not work with a new app built this way.

Collaborator accounts cannot use the Dev Dashboard. Shopify’s help documentation states collaborators do not have organisation-level permissions, so they cannot access it. If your agency works through a collaborator account — which is how most agencies work — you cannot create the app yourself. Either the store owner creates it, or you are given a staff account with the Develop permission.

Protected customer data needs approval. Scopes that touch protected customer data require a request to Shopify. On the merchant side, access to Custom Level 2 PII apps requires the store to be on the Grow plan or higher. If your build reads customer PII and the client is on Basic, you have a plan conversation before you have a code conversation. Sort this out on day one of a project, not on the day you need to ship.

If you have existing custom apps: nothing. They work. Do not let anyone sell you a “custom app migration” you do not need. If a token gets lost on a legacy app, you cannot reveal it twice. You uninstall and reinstall to generate a new one — and uninstalling deregisters webhooks and carrier services, which your developer must register again.

If you are planning a new integration: budget for the OAuth work. Ask your vendor directly how they will handle token refresh. A vendor who says “we’ll just grab the token from admin” has not read the 2026 documentation. If you use a third-party connector, check with that vendor how their 2026 setup works — several published new guides in early 2026 specifically because of this change.

Move new builds to the Shopify CLI where the app is real software, not a token holder. Config lives in the repo, versions are tracked, authentication is handled in development. Implement client credentials grant properly for own-store integrations, with refresh handling and a fallback for a failed token request. Never hardcode a token — twenty-four hours from now it is a support ticket.

Wire scopes into your release process. New scopes need merchant approval, so a scope change is a coordinated release, not a silent deploy. Keep a plain-language note in the client’s handover doc explaining the new install path. AiSalesQ tracks Shopify platform changes like this one closely so our own integration never breaks under you.

The 2026 change does not alter this decision, but it does raise the cost of getting it wrong, because every custom build now carries real authentication work.

Use an App Store app when the feature is standard across thousands of stores — reviews, popups, basic upsells, shipping rules. Someone already maintains it, and they maintain it for the next Shopify platform change too.

Use a custom app when the logic is specific to your business and stable enough to be worth owning — ERP and inventory sync, proprietary pricing, internal tooling, data models nobody else has.

Build a public app when the problem is not yours alone and the app is a product, not an integration. That is a different business decision entirely.

The honest test: if you could describe your requirement to a merchant in a different industry and they would nod, buy the app. If they would look confused, build it.

AiSalesQ builds Shopify apps in both directions — custom apps for single merchants, and public apps published on the Shopify App Store. The App Store side is why we track platform changes like this one closely: our own apps have to keep working through them.