Development discussions around Shopify APIs
Looking for an enumeration (list of all available options) of plan_name when you're doing a GET request to the /admin/shop.json
I've noticed that there a few, with a subset of others?
Trial: trial Trial from Partner: affiliate Basic Shopify: basic Shopify: professional Advanced Shopify: unlimited Shopify Plus (Enterprise): enterprise
Are there any others?
Also, shopify documentation team, I'd really appreciate this being documented in your documentation _somewhere_.
There are more!
custom singtel_basic singtel_unlimited dormant
Submitted an application for beta testing -- Shopify staff shops have the plan_name of "staff".
Same question here.
Does anyone from Shopify care to give us the full list here?
In my case, I use the analytics api but this is not available for all plans and I want to let the user know that depending on their plan...
Thanks Zac for looking into this.
Did you figure out if trial shops have the same permissions as the advanced plan?
Shopify don't seem to be super helpful in terms of giving plan names away. I'll find the email chain once I get back into the office on Monday. From what tests I have done, trial and affiliate plans both have the access rites of the Advanced plan. As in, access to all analytics etc.
This should definitely be documented somewhere IMO, even if it may change in the future...
Here's a copy of an email from Josh @ Shopify.
Hi Zac, Josh here from the Shopify developer relations team. Thanks for reaching out :) We don't provide a complete list of values for that field, but I can give you some of the common ones: professional, npo_lite, custom, grandfather, unlimited, staff, affiliate, trial, dormant, npo_full, basic, comped, starter, business, frozen, shopify_plus Hope this helps! Josh @ Shopify
Thanks for that Zac.
Some of those names are really not very descriptive here. (npo_lite, singtel_basic...)
And If I understand there is 'enterprise' and also 'shopify_plus' for the same Plus plan...
As far as API permission, I wonder if the easiest thing to do is to try do an API call and see if it succeeds! (Rather than relying on the plan name...)
That sounds like the best idea in terms of knowing instantly.
Doesn't really work for my main issue though, that a biling api sent to a trial store throws a error and takes the user both out of the app and out of their store backend.
Hmm that's no good.
Do you mean when you try to issue a recurring charge? I was able to do it on trial accounts, but I only used test charges so far...
Just non-test charges.
Set up a lot of logic which simply checks the plan name they have, and if it's affiliate or trial -- send them to a page requesting they upgrade their plan before trying to do something specific, like upgrading the app package etc.
Hmm I see. I will have to implement something similar...
The way I've implemented this is by having middleware which is queried every request after the user has completed the install procedure for the app.
If the store plan matches one of the trial types, set a value in REDIS for their store to say that they are a trial user with a 30 minute timeout (in case they upgrade, but also doesn't hammer the shopify api limiter).
If the store isn't -- redirect them to the payment page which redirects them to the "pls confirm payment" thing in Shopify. Once they have done that, set a value in REDIS to say that this store has payed. On uninstall remove the REDIS key so they don't get no free 30 minutes of app usage etc.
Then the middleware just checks to see if this key exists in redis, otherwise normal query stuff.
Trial users I've blocked from upgrading the app plan, they just get redirected to the upgrade store plan page as said above.
Apparently cancelled is another possible value.
These values really need to be documented. App developers need to know what these values imply, esp, the causes and consequences of the values frozen, cancelled, and dormant.
For apps that need to keep an accurate track of a shop's purchase history, I believe the plan_name attribute in the shop/update webhook callback is the only thing that could be used to reliably trigger a disconnect process.
I checked our database to see what values we have and this is what i found:
"affiliate", "staff", "professional", "custom", "shopify_plus", "unlimited", "basic", "cancelled", "staff_business", "trial", "dormant", "frozen", "singtel_unlimited", "npo_lite", "singtel_professional", "singtel_trial", "npo_full", "business", "singtel_basic", "uafrica_professional", "sales_training", "singtel_starter", "uafrica_basic", "fraudulent", "enterprise", "starter", "comped", "shopify_alumni"
The information provided above will be more useful if we knew what the plan_names translated to, and how if affects a developer
looks like another plan name exist. "partner_test"
Hope you're having a great day!
I checked our database to see what values we have and this is what i found:"affiliate", "staff", "professional", "custom", "shopify_plus", "unlimited", "basic", "cancelled", "staff_business", "trial", "dormant", "frozen", "singtel_unlimited", "npo_lite", "singtel_professional", "singtel_trial", "npo_full", "business", "singtel_basic", "uafrica_professional", "sales_training", "singtel_starter", "uafrica_basic", "fraudulent", "enterprise", "starter", "comped", "shopify_alumni"
Thanks a lot.
Thanks to all Community members that participated in our inaugural 2 week AMA on the new E...By Jacqui Mar 10, 2023
Upskill and stand out with the new Shopify Foundations Certification programBy SarahF_Shopify Mar 6, 2023
One of the key components to running a successful online business is having clear and co...By Ollie Mar 6, 2023