Script tags have been deprecated since 2021, when theme app extensions replaced them. They’re already removed from the Order status page, and now we’re announcing deprecation dates for storefronts.
From October 1, 2026, scriptTagCreate and scriptTagUpdate will return a user error, and the REST ScriptTag resource stops accepting POST and PUT. Existing tags will keep running, and you can still read and delete them.
From March 1, 2027, we’ll stop injecting script tags into storefronts.
If your app loads JavaScript with a script tag, then move it to an app embed block in a theme app extension. If the script only collects analytics or conversion data, then use a web pixel instead.
Will there be a way to programmatically enable an app embed block for existing users? We have thousands of merchants using ScriptTags, and relying on each one to click a deep link from an email or return to the app dashboard feels daunting.
Agree with jlyon. There should be a programmatis way for existing merchants to migrate to app embed. They are already have custom code running, so I don’t see any permissions issue with this. A lot of merchants will result in broken experience without
We need to have a way to get it enabled programatically. Please let us know what the team says. There are thousands of customers that aren’t very technical we’d have to get through the process.
@misha, we still have about 80 merchants using our app on legacy themes, which depend on Script Tags to work correctly.
While we have not created new script tags in a few years and have migrated the app to App Blocks, there’s not much we could do for merchants using legacy themes.
When (and IF) they open the app, they just see a notification asking them to update the theme, or uninstall the Script Tag. Uninstalling the app also delete the Script Tag permanently. All we can do is delete the Scrip Tag.
Are we supposed to email everyone and hope they see the message and respond, and then migrate to a new theme? This is not an easy task. Also, will Shopify show some kind of alert for merchants on legacy themes?
I looked into this gap in some detail after seeing the ask here for a
programmatic way to enable app embed blocks for existing installs, and
wanted to share findings in case it’s useful for whatever your team
ends up scoping.
First: I confirmed there isn’t currently a documented app-side write
path that would be sanctioned under the App Store Requirements
(section 5.1.1 asks apps to use theme app extensions rather than
directly modifying theme files, and I couldn’t find any example of an
app writing to config/settings_data.json in production). So the
“just have apps patch it themselves” route seems correctly closed off,
which probably isn’t news to your team but wanted to confirm it from
the outside.
What would actually solve this cleanly, from a technical standpoint, is
a first-party bulk-activation endpoint – something like a mutation
that lets an app request activation of its own embed block across a
merchant’s installed themes, gated behind the same install-time
permission scope the app already has (so it’s not bypassing merchant
consent, just extending the consent that already exists at install
time to cover this one migration action). I put together and tested an
idempotent patch function against the real settings_data.json schema
(handles: block doesn’t exist yet, block exists but disabled, multiple
unrelated blocks/sections that need to survive untouched, and the
preset-as-string-reference case that seems to be behind the corruption
bug reported elsewhere in this forum) – happy to share the reference
implementation if it’s useful input for whatever the safe server-side
version of this would look like.
Given the March 2027 hard cutoff and the number of merchants cited
upthread, is there anything more concrete on the roadmap for this, or
a better channel (partner support ticket, etc.) to push on it?
I have been made aware of this topic via email today.
Of course, I knew that ScriptTags were meant to be completely deprecated at some point. But were there earlier emails about this specific timeline (that I have missed then, my bad )? If not : isn’t the first deadline on October 1st a bit short? We obviously need to put an alternative in place before then to avoid using ScriptTags (creating an app embed, making an interface to have new users activate it and checking they’ve done so).
Also, I would agree with others saying that a migration for already active ScriptTags to active AppEmbeds without needing action from the merchant would be very useful, for the following reasons:
Some users just no longer open the app (even though they are using the features for their visitors). And they may not notice that it’s no longer working (for instance we display popups displayed in very specific cases or hide them at some point to regular users … like the store owner). They may end up paying for something broken.
Old users are already seeing the app features working. Even if they open the app, they may dismiss our warnings without activating the app embed.
Of course, we will reach out to them via email. However, from experience (doing support via email), the email address attached to the shop sometimes doesn’t work or it is the owner’s address while the app is managed by an outside marketing company (or a generic support address not reaching the team in charge of managing apps for big companies). Also, emails may end up in spam folders (especially when it comes from domains who don’t send a lot like ours).
Anyway, I don’t mind making the migration, of course. I am just for making it as smooth as possible for both merchants and partners!
But basically we have not used script tag API for years, we do not have the access scopes any more and somehow we received the email that a banner will be shown to all new installs about script tags?
@misha We received this notice for several of our apps, all of which moved to app embed blocks long time ago. The remaining script tags are from older installs where the merchant never turned the embed on, plus stores that are paused, frozen or closed.
How does Shopify decide that an app “uses script tags” for the install banner warning for new users? Is it based on the requested access scopes, existing script tags on stores, or recent API calls? Our apps already ship app embed blocks, and we want to confirm new merchants won’t see a warning when they install.
Is there a way to enable an app embed programmatically, or with one-click merchant approval, for stores that already run our script tag? They have already agreed to our code running on their storefront.
Could the Partner Dashboard offer a way to deactivate an app’s remaining script tags in bulk, including on paused or frozen stores where the Admin API can’t be reached?
I knew ScriptTag were legacy but I have never been told they were deprecated. And now I get an email they are getting deprecated with 6 days until the deadline!!? I still rely on it for all my users. Why wasn’t I notified before? Why was there no mention of this in the dev dashboard?
It’s like things are getting steadily worse when it comes to communication from Shopify. The review dilemma and the offline access token migration. It’s getting ridiculous.
Thanks for all the feedback here and in the other thread. We heard you, and we’re not shipping the install warning planned for October 1. The dev docs will be updated to reflect that change shortly.
Many of you have leftover script tags on frozen or paused stores that you can’t delete, so the warning would have flagged apps that migrated off years ago. Our email also made the warning sound much broader than it was. Both are on us.
The rest of the timeline hasn’t changed. From October 1 you can’t create or update script tags, and on March 1, 2027 they stop running on storefronts.
The Dev Dashboard notice should have been live since the original announcement in August. An issue kept it from showing up, and it’ll start appearing in the next few days.
We’ll keep an eye on script tag usage through Q4 and look at it again in January. If we decide more targeted notices are needed for apps that haven’t shipped a replacement, we’ll announce them in the developer changelog and the Dev Dashboard with ample time to act.
… so you confirm we haven’t been notified before due to a bug, and we will now start to see it in a few days, but you will continue disabling the creation of script tags on October 1st anyway? I’m getting tired of the mess Shopify is causing for partners in 2026.
@misha, while most of our clients that still have ScriptTags are indeed frozen or paused stores, we still have some active and paying merchants with ScriptTags. They have been happily running on Legacy Themes, which do not support the new app blocks that our app provides.
If you remove ScriptTags in March, you’ll be breaking functionality for these live stores. My view is, since Legacy themes are still allowed to run on Shopify, ScriptTags should continue to be supported on those.
Removing those is like allowing an old car to still be on the road, while forcing the removal of one its wheels. This kind of partial-deprecation adds a lot of friction.
My suggestion would be, if ScriptTags really need to go, then it would be on Shopify to first ensure all merchants migrate to new themes, so they can re-add the functionality they need via app blocks or other newer features.
I assume most apps that still have active ScriptTags also have had an alternative app block implementation for a while. At least that’s our case.
Hi @misha, thanks for dropping the install warning.
Our situation is the one described above. Four of our apps moved to app embeds many years ago and haven’t created a script tag since. It is completely safe to delete every leftover script tag from these apps on any store.
The leftover tags sit on stores that have been closed, frozen or paused for years. As long as the tags are there, our apps get counted as “using script tags,” and we’re exposed to whatever notice or warning comes next.
This is the second time we’ve been through this. In February 2025, during the Order status page change, we filled in the script tag form for all four apps. Support confirmed the script tags had been removed and said the App Review team would check again to make sure they were deleted. This month’s notice listed all four apps again.
We’d like to settle this permanently instead of coming back to it each time the timeline changes. Please remove all script tags created by our apps from every store, including closed, frozen and paused ones, and confirm once it’s done so our apps are no longer counted. We’ve already confirmed this in support ticket 70582532.
)? If not : isn’t the first deadline on October 1st a bit short? We obviously need to put an alternative in place before then to avoid using ScriptTags (creating an app embed, making an interface to have new users activate it and checking they’ve done so).