Shopify app detector: what it reads, and how to read it yourself

A Shopify app detector matches patterns in a store's public HTML against a list of known app signatures. On most stores it does not have to guess, because a modern Shopify app ships as a theme app extension, and Shopify serves that extension's files from its own CDN under a path that spells out the app's handle and version. You can read that list yourself in one command. ShopLeads is our product and it sells store and contact data, so we say so; this page is about reading app data off a store, and the apps a detector cannot see at all.

Everything below was read from each store's own homepage on November 9, 2026, and every store named answered as a live Shopify storefront that day.

Read the apps on a store in one command

curl -s https://www.bando.com/ | grep -o 'cdn.shopify.com/extensions/[^"]*'

For ban.do that returned four asset URLs under three extensions:

• /extensions/01a1b19f.../gdpr-cookie-consent-427/assets/pandectes-core.js
• /extensions/01a1c170.../loop-returns-532/assets/onstore-block.js
• /extensions/01a19c24.../sc-easy-redirects-18/assets/esc-redirect-app.js

Three apps, named, with no tool and no sign-up. The structure is /extensions/{installation id}/{extension handle}-{version}/assets/{file}, and it exists because theme app extensions host their assets on the Shopify CDN rather than editing theme code, which is the whole point of the framework (Shopify.dev).

The handle is a lead; the asset filename is the proof

This is where the free detectors differ from each other, and where they get names wrong. The extension handle is chosen by the app developer for the extension, not for the App Store listing, so the two sometimes match and sometimes do not. Of the eighteen distinct extension handles we read across the stores below, six resolved directly as an App Store listing when we stripped the trailing version number and requested apps.shopify.com/{handle}. The asset filename settled the rest.

When a detector hands you an app name that sounds like a category rather than a product, it almost certainly read the extension handle and stopped. Grep the asset filenames and you will usually find the vendor spelled out.

Seven real stores and the apps they load today

Two patterns in that table are the real finding. First, consent apps are everywhere and they are the single most common extension we saw, which tells you more about regulation than about merchandising. Second, three of the seven stores run at least one app that exists only for them. A detector will either skip that row or report its handle as a product name, and in both cases the honest answer is "custom".

What a Shopify app checker cannot see

Every detector reads the page a shopper's browser loads, so the boundary of what it can know is the boundary of that page. Four classes of app sit outside it.

• **Back-office apps.** Accounting, inventory sync, shipping labels, fulfillment, purchase orders, wholesale pricing. They do their work in the admin and never touch the storefront, so there is nothing to detect. Every honest vendor page says this, and it is the biggest single gap.
• **Apps that run as sandboxed pixels.** Shopify's Web Pixels API loads app pixels inside a strict sandbox and custom pixels inside a lax one, with a controlled set of browser APIs. A pixel that subscribes to customer events through that API does not have to look like a familiar script tag in the page.
• **Anything injected after the page loads.** Scripts added by a tag manager, by a consent gate, or only on a product or cart page will not appear in the homepage HTML. The two stores in our sample with no extension assets at all, Allbirds and Gymshark, both load third-party tooling another way.
• **Apps installed but switched off.** An extension can be present in the theme and disabled in the merchant's settings, or enabled for one market and not another. The asset still loads. The app is still billed. Whether it is doing anything is not in the HTML.

That last point cuts the other way too. Allbirds returned no theme app extension assets at all on our read, and Gymshark returned none either, yet both are large stores that obviously run tooling. Larger brands build more of their storefront themselves and route third-party scripts through their own tag setup, which means a detector tends to under-report exactly the stores you most want to understand.

How many apps each detector claims to know

Read those two columns together and the trade-off is clear. The single-store tools know more app signatures and answer one store at a time. Wappalyzer knows far fewer apps but publishes how common each one is: its Shopify apps page today puts Pandectes at the top of the list with around 29,000 tracked sites, then Smile at about 26,000 (Wappalyzer). If you are deciding whether an app is worth building against, that second kind of number is the one you need.

Finding every store that runs an app, instead of checking one at a time

A detector answers "what does this store run". If you sell apps, themes, or agency work, your real question is the reverse: which stores run the thing I integrate with or replace, and who there decides. A lookup cannot answer that, because a lookup is one store deep.

1. Pick the app or the gap you sell against, and write down the exact name. App filters match on names, and "reviews app" is not a name.
2. Filter a store index to it, then throw away everything that is not a real brand. Development stores and template clones carry app assets like anyone else.
3. Add a size cut so the list is stores that can afford you, and a category cut so your opener is about their business.
4. Add the person before you export: decision-makers only, in the departments that own the tool you are replacing, with a work email whose status you can see.
5. Open the store before you write. Its app assets, its product list and when it last published a product give you the one specific line that makes an email look addressed.

ShopLeads keeps the apps and technologies installed on each store as named filters, and it keeps the gaps too: no email or SMS platform, no reviews app, no subscriptions, no loyalty, no helpdesk, no upsell. The store filters and the people filters are one search, so the result is the stores plus the decision-makers at them. Searching and counting are free and never reveal a contact, and a free preview shows the exact cost before a credit is spent. Browse the Shopify store directory, read how a theme detector reads the same HTML and the four searches behind "search Shopify stores", then start the free trial or see the pricing page.

Before you trust any app list, confirm the store is on Shopify: a technology checker reads a site the same way, and a headless storefront serves no theme app extensions at all, which a detector will report as "no apps" rather than "wrong question".

Where to go next

• What a Shopify theme detector really tells you reads the same block of HTML for a different field.
• What technographic data is and where it comes from explains what an app list is worth once you have one.
• At list scale rather than per store: ShopLeads vs BuiltWith, and BuiltWith alternatives.
• The stores themselves: the Shopify store directory.
• Watch the launch film, or read the pricing page.