something like google’s file picker, which doesn’t require any special access and uses a non-sensitive scope
Interesting question @jay123! Shopify’s OAuth/installation flow is store-specific - you need to know the shop domain upfront before starting the installation process. There’s no native “store picker” in the flow like Google’s file picker where users browse and select from their accessible stores.
If you’re building an app where users have multiple stores and want to select which ones to connect, you’d need to build that selector UI yourself in your app, then initiate separate installations for each store they select. You’d store the multiple access tokens (one per store) in your database keyed to the user.
Can you share more about what you’re trying to build? Are your users merchants with multiple stores, or are you building a Partner tool? That’ll help me point you to the right approach.
you need to know the shop domain upfront
build that selector UI yourself in your app
How do those two fit together? If I have to know the shop domain before the OAuth flow even starts, how am I supposed to build a selector UI when I don’t know the user’s stores yet?
My use case: I’m building a marketplace that lets Shopify admins import products and inventory. The app won’t be listed in the Shopify App Store, and all interaction happens inside the marketplace, not inside the Shopify admin. I want a flow where the user can pick which of their stores to connect - similar to Google’s file picker that works with a non-sensitive scope and doesn’t require pre-known identifiers.
Thanks for that additional context @jay123, I see where you’re coming from!
The fundamental difference is that Shopify doesn’t have an API that returns “all stores owned by this user” the way Google’s APIs work. Shopify’s OAuth flow is intentionally shop-specific from the start. Every authorization request requires the shop parameter (the myshopify.com domain) before you even redirect the user to authenticate. This is by design for security and data isolation.
Google has a centralized account system where you authenticate once, then Google returns a list of resources (drives, files, etc.) tied to that account. Shopify doesn’t work that way - from an OAuth/API access perspective there’s no “parent Shopify account” that owns multiple stores. The only way your app learns about a store is when the user explicitly provides the shop domain and completes OAuth for it.
So when I mentioned building a selector UI, what that actually means in practice is that you’d ask users to manually enter their shop domain (example.myshopify.com), then initiate OAuth for that specific store. If they have multiple stores, you can either collect all the domains upfront or let them add stores progressively - start with one connection, then give them an “Add another store” option that repeats the process.
Your app would store all the access tokens keyed to each shop domain and the user account in your marketplace system.
There is actually an API that returns “all stores owned by this user.” It’s not part of the public OAuth flow, but it absolutely exists. Shopify’s admin.shopify.com GraphQL endpoint exposes the full list of stores tied to the logged-in user account:
POST https://admin.shopify.com/api/destinations
{ "query": " { currentUserAccount { … } }" }
That query returns every store (organization or orphan) the user has access to — including metadata, domains, icons, etc. So the statement that “Shopify doesn’t have an API for this” is simply incorrect.
Second: Google’s Drive Picker exists because it avoids the problem you’re describing. The whole point is strong isolation by default + a user-controlled selection step. My code gets access only to the specific file(s) the user selects and nothing else. The equivalent in Shopify would be giving me access only to the store the user selects — which is exactly why a picker makes sense.
Third: if I have to ask the user to type their store domain manually, then the selector UI becomes pointless. At that point it’s not a selector, it’s a text field. And if the user already has authenticated identity with Shopify, forcing them to recall/guess their store domains instead of selecting from the stores Shopify already knows about is a bad UX and unnecessary friction.
So to summarise:
- Shopify does have a “list of my stores” API — it’s just not exposed in a way that third-party apps can formally rely on.
- Google’s picker model is intentionally designed for granular access and security.
- A “build your own selector UI” is meaningless if the user has to provide shop domains manually.
You’re right, I wasn’t accurate enough in my wording.
The distinction I should have made clearer is that there isn’t a public API that allows you to do this. The /destinations endpoint used by admin.shopify.com is not documented on shopify.dev, isn’t covered by our Terms of Service and versioning schedule, and is liable to change at any time making it unsuitable for use by third-party apps.
I do understand the frustration with manual entry. The reality is that Shopify’s public APIs treat each store as an independent authorization scope, and there’s no supported API for third-party apps to discover stores a user has access to before completing OAuth for a specific shop.
Since there’s no native way to achieve what you’re hoping to do, I’ve logged this as a feature request internally - the use case makes sense and I can see why you’d expect this to work like other platforms.