Shop domain used during install and authorization

Authentication & Access
1

Hi!

We’ve noticed that when some customers install our application and try to connect their shop to our system(we are usingauthorization_code_grant flow), the shopname they provide does not match the one used in the OAuth flow. From what we are seeing, it looks like Shopify may be using a redirect shop domain in the auth flow rather than the primary or alias one.

A couple of questions:

  1. If a store has multiple domains, which one should app treat as the source of truth during install and authorization?

  2. Is there a proper way to consistently identify the correct shop domain for install/auth?

Our goal is to make sure we rely on the correct shop name and can explain this behavior clearly to customers when they notice a different shopname during authorization.

Any clarification would be really appreciated. Thanks in advance.

2

Hey @SPS_Commerce! The shop parameter in the OAuth authorization code grant flow always uses the store’s original .myshopify.com domain, not a custom domain or any alias. The authorization code grant guide requires apps to validate this in Step 3 with a regex that enforces the *.myshopify.com pattern.

Even if a merchant has updated their displayed myshopify.com URL or added a custom domain, the shop parameter in OAuth will still use the original one. This is consistent across the install request, the authorization redirect, and the callback. Merchants may not realize this domain is different from what they see in their admin, which explains the mismatch you’re running into.

After obtaining the access token, you can query the Shop object to get both the stable identifier and the domain info you need:

{
  shop {
    id
    myshopifyDomain
    name
    primaryDomain {
      url
      host
    }
  }
}

The id field (the Shop GID) is the most reliable identifier for a store and will never change. myshopifyDomain returns the same .myshopify.com domain that OAuth uses, and primaryDomain returns whichever domain the merchant has set as their storefront’s primary (could be a custom domain or the myshopify domain itself). Between those fields you should be able to reconcile things on your side and explain the difference to your customers when they notice it.

1 Like
3

Hey @Donal-Shopify, thanks for clarification.

One follow-up question: is there a reliable way for a merchant to identify which of their shop domains is the original one, for example from their profile/settings/anywhere else in Shopify?

At the moment, our app installation flow requires the merchant to provide a shopname so we can correctly identify the merchant in our system.

4

Hi @SPS_Commerce

The original domain name is included in the store URL.

图片

5

There isn’t a reliable way for a merchant to identify the original .myshopify.com domain from the admin. The Domains page (Settings > Domains) lists all connected .myshopify.com domains, but if the merchant has changed theirs, both appear with no label distinguishing which is the original. The admin URL in the browser bar uses the newer “branded” one too, not the original. I verified this on a dev store that has both a permanent and a branded .myshopify.com domain.

On that same store, I tested the OAuth authorization code grant flow and the shop parameter consistently used the original .myshopify.com domain in all three steps (install request, authorization redirect, and callback), regardless of which admin URL the merchant navigated from. The myshopifyDomain field from the Shop query also returned the original domain, not the branded one.

I’d recommend capturing the shop parameter directly from the OAuth flow rather than asking merchants to provide it manually. If your install flow is app-initiated (where the merchant enters their shop domain on your side to kick off the OAuth redirect), some manual input is unavoidable for that first step, but the shop value Shopify sends back in the callback is what your app should persist as the store identifier. That, combined with the Shop query from my earlier reply, should cover both identification and reconciliation on your side.