Covers all questions related to inventory management, order fulfillment, and shipping.
Hi all,
We have two different portals (merchant and self-serve) that are built using separate database and backend. These two portals serves different clients. Since the merchant and self-serve portals are hosted on different domains, is it possible to add extra query parameter to Shopify's callback? For example, instead of using https://apps.shopify.com/janio-asia as the installation link, we could use https://apps.shopify.com/janio-asia?origin=merchant instead and hopefully that "origin" query parameter would be returned as part of the callback url.
Problem:
After looking at the Shopify documentation, we see that the Shopify redirect callback only returns the following parameters:
Example callback url: https://fixed-callback-url.com/callback?code=abc&hmac=test&host=abc&shop=abc.myshopify.com×tamp...
None of the parameters could help us identify the origin of the request. Without a way to identify where they are coming from (merchant or self-serve portal), we are unable to redirect the users back to the correct portal.
What we have tried
We have previously released a Shopify app that redirects user to the merchant portal after authentication. We also submitted another app with a different redirect url. We thought that having two different apps would solve the problem as they have different redirect urls in the app setup. But Shopify have rejected the app on the grounds that both apps have identical functionality.
Any helps or suggestion would be greatly appreciated. Thank you!
Your question is unclear. It is clear that you do only need one App, as running two instances of the same codebase to service the same clients (but differing only in where they come from) is a poor operational choice, for many obvious reasons.
So you have one install link, and thus your App can serve many stores. Shopify has no problem with that.
Where your explanation loses clarity is a lack of definition of these sources. What is a portal? What is a merchant portal? What is a self-serve portal. What would you run separate databases if the only thing different is this definition? Why not just have a column "source" of type merchant or self-serve?
You can draw boxes and arrows and explain your needs easier than words perhaps. Attach an image to your request so experts can try and deduce what it is you are trying to do.
Just trying to be helpful....
Hi HunkyBill,
Apologies for the unclear explanation. My bad for using vague terms. Portal = website. Merchant and self-serve portals are two different websites (screenshot below) that are built to serve different merchant demographics. Bigger enterprise merchants will use the merchant website and smaller merchants will use the self-serve website. Both websites are hosted on two different domains (merchant.janio.asia and ss.janio.asia).
Here's the general flow of the integration for both website:
What we want to achieve
How could we dynamically define the redirection url after authorisation? For example, if merchant are coming from the self-serve site (ss.janio.asia), after installing our app, they should be redirected to https://ss.janio.asia/channel/shopify/callback?code=xyz&hmac=abc&host=123&shop=test.myshopify.com×tamp=1631765608.
The problem we are facing now is that the redirection url seems to be fixed (i.e either redirect to the merchant website or ss website). And we do not know where the merchant is coming from without an identifier. That is why we created two separate apps with two different redirection url. The rationale is merchants that have enterprise account will install Merchant App (which will redirect them to merchant.janio.asia) and smaller merchants will install Self-Serve App (which will redirect them to ss.janio.asia).
But, I agree with your point that it's not ideal. We would also like to avoid having redundant apps if possible.
Hope it's clearer now. Please let me know if the explanation above is still vague. Many thanks for your pointers!
In both cases, your customers, in this case Shopify merchants, are not logged into a Shopify store. From what your screenshots show, both sites are under your control. So what is happening here? What is the purpose of your App? Why does it exist? If a merchant chooses to login to one of your sites, why would they then install this Shopify App? What does your App specifically bring to the table for any Shopify merchant? If you can answer that, perhaps we can help you more.
Sure thing. We are a logistic company. Both sites that I shared in the screenshot earlier are dashboard for merchants to handle their deliveries. Some merchants wanted to ship their Shopify orders with us. Before introducing the app, merchants had to manually export the orders from Shopify and import into our dashboard, which is less than ideal experience for them. That is why we created the app, so that any new orders that were created in Shopify can be automatically pushed to our sites, and from there, they can choose which orders to ship with us. Hope that makes sense. Thanks again.
I would do it this way then. Your App is a fulfillment service. When installed, the installation sits in your single database, where you have access to your shops that have installed your App. You access these shops by way of overlaying an Admin App with access to your Shopify App DB. Simple. I do it all the time. From that Admin view, you can ensure each shop is labelled properly as in portal or self-service. You could even ask the merchant to tick that off, so that once the Shopify oAuth install finishes, your After Install hook sets the choice they made. In fact, since they are pre-enrolled in your portal or self-serve, you already have a Shop record, and so then the whole oAuth just happens off that record, in the single DB, and all you save is the name of the shop and access token as per usual.
Fulfillment Service code then ensures you can handle their deliveries, and that sending you orders is trivial for the merchant. Obviously any delivery service for merchants on Shopify is going this route. Right?
Unless you've architected some crazy thing, I cannot see how your architecture is going to differ from this suggestion without being close to unworkable or a PITA for the merchant. Let me know if that makes sense.
Hi Bill,
Thanks a lot for your suggestion. Ya, that makes sense. Let us try that. But do you have any comment on my original question, about the ability to pass extra metadata to the Shopify app? I am curious if that possibility exists.
Even if you could append a parameter of your liking and choice, to the oAuth flow, you'd perpetuate a bad architecture all because it was easy to do? Yay for progress!
I am not sure you can do this. First off, Shopify oAuth flow is out of your control. When you hit the Shopify oAuth, go right ahead. Attach any params you want!! See what you get back. Answer your own question! It takes seconds, since you already have that flow under your control in your App. Do a quick debug.
Fair point. Just tried the debugging. It's not working :). I guess there is no way to add an extra params after all. Thanks for your feedback and suggestions, Bill.
All the best! Like I say. Save yourself a ton of hassles. Go with ONE DB and one App. You do not need to complicate your life with two versions to support essentially the same service.