Unlisted public app - is Shopify Billing API mandatory, or can we use Stripe?

Shopify App Store
1

We’re building a SaaS product (shipping/storage/support services) that needs read access to a merchant’s orders and products via the Shopify API. Our clients come to us through our own website and sales channels — not through the Shopify App Store.

Our situation:

  • We don’t need App Store discovery — all installs happen via direct install link from our website

  • We currently use a custom app, but that’s limited to a single store (or Plus organization)

  • We want to scale to multiple merchants without creating a separate custom app for each one

  • An unlisted public app seems like the right fit — we get OAuth + API access for multiple stores without App Store listing

The core question:
For an unlisted public app distributed exclusively via direct install link (never listed on the App Store), are we required to use the Shopify Billing API for charging merchants? Or can we bill our customers directly through Stripe since they’re our existing clients who found us outside of Shopify?

Our product isn’t really a “Shopify app” in the traditional sense — it’s a standalone SaaS platform that uses Shopify as a data connector. Merchants pay us for shipping and storage services, not for a Shopify app. The Shopify integration is just one piece of a larger product.

What I’ve read so far:

  • The Shopify API Terms mention revenue share obligations for apps distributed through Shopify

  • Custom apps are exempt from revenue share but can’t scale beyond one store/Plus org

  • The distinction for unlisted public apps isn’t clearly documented

How are others handling this? If you have a SaaS product that just needs API access to multiple Shopify stores, what’s the recommended pattern — unlisted public app with your own billing, or something else entirely?

Thanks in advance.

1 Like
2

You don’t need to use it unless you submit it for review.

3

without submitting it for review, shopify is not letting us install it on any store that is generating revenue. It can only be installed on dev stores. we tried every possible combination. We tried doing a custom app (however we can only install the custom app on 1 shopify store).

Maybe something has changed in 2026? All online documentation seems to contradict what I’m seeing through the new partners app development experience

4

Hey @pd1 :waving_hand: You’re on the right path with unlisted apps but all public apps, including unlisted ones, must pass app review before they can install on production stores.

The Billing API is mandatory for App Store-distributed apps, however I have seen exemptions given in similar cases to the one you describe. When you submit for review, note in your test instructions that you’re requesting a Billing API exemption and that you agree to be permanently locked to limited visibility and the App Review team will assess your eligibility for an exemption.

1 Like
5

We just went through almost this exact situation and wanted to share what happened in case it helps others.

We’re building a data platform – Shopify is one of hundreds of sources we connect to. We’re not a Shopify-native product, we don’t acquire customers through the App Store, and the app itself is purely necessary to get tokens through OAuth for existing customers to connect their store. Previously our customers were sharing their access tokens but since those are no longer an option with new stores from the breaking change in Jan - we hoped to move to using OAuth tokens instead with a single Shopify app managing the token grants/flow. We use OAuth for dozen of similar other api integration, with no review problems, so we expected doing this with Shopify would be simple…

We were in app review pending state for about ~4-5 weeks, then have been chatting with an app reviewer at Shopify for the last week+ trying to understand the token and billing requirements.

We found this thread during our review and followed @Donal-Shopify advice – formally requested a Billing API exemption and agreed to be permanently locked to limited visibility. Felt like exactly the right path for our situation.

However, our reviewer came back and told us that exemptions based on limited visibility are no longer being granted due to a new policy update. I’m not totally sure where this policy change is yet or the documentation(maybe if someone has it they can share). Given that @Donal-Shopify post is only 23 days old, it was pretty confusing and contradictory to get that response.

We’ve also been going back and forth trying to explain that we don’t expect any new customers through the App Store – every install is an existing customer connecting their shopify store as a data source. The communication seems to be that there is no longer any billing exemptions and that all public apps are required to implement rev share and billing api integration.

Still trying to find a path forward. Has anyone else run into this recently or found a way through it? I’m really at a loss here for what to do next? This has been a thoroughly painful process that is effecting dozens, potentially hundreds, of customer integrations and we do have not path to onboard the dozens of new customer integrations that have been blocked since January. The communication that we’ve last received in review was to ask other developers in these forums for recommendations on next steps which is disheartening to say the least.

@Donal-Shopify as Shopify staff can you give me any official information or guidance so i’m not just grasping at straws and reading out of date information

6

@dmb My March 9 advice was wrong. The policy on limited visibility exemptions changed that same week, and I didn’t catch it before posting. Sorry about that.

The current policy is that limited visibility exemptions are no longer being granted. All public apps, including unlisted ones distributed via direct install link, must use the Billing API or Managed Pricing for any charges.

I know this doesn’t accommodate the “SaaS platform where Shopify is one of many data connectors” use case well. The current policy treats you like a Shopify-native app even though you’re not. I don’t have a better answer right now and can’t promise this will change, but I’ll make sure this feedback gets visibility with the relevant teams.

7

There’s another path that might work better for your use case.

Instead of a public app, your customers could create custom apps in their own Dev Dashboard and share the Client ID and Client Secret with your platform. Your platform then uses the client credentials grant to generate access tokens on their behalf. This is essentially the same as the old flow where merchants shared static access tokens, except the tokens now expire after 24 hours and need to be refreshed.

The upside is that custom apps don’t require App Review or Billing API. The downside is slightly more onboarding friction (merchant creates app, copies credentials to your platform) and your platform needs to handle token refresh. But if you’re already set up to store credentials per-merchant, adding a token refresh call every 24 hours is straightforward. This tutorial has code examples for how to handle the grant.

This was confirmed as a valid approach in this thread where Kellan explicitly mentioned it as an option for similar use cases.

8

Hey Donal,

Thanks for the honest response and for flagging the policy change. It’s frustrating but we genuinely appreciate the transparency.

We’ll likely go the custom app route for now, but wanted to share some feedback on why this use case is harder than it might look, in case it’s useful for the teams you’re passing this to.

The multi-store problem

Several of our customers have dozens of Shopify stores. Managing a separate custom app per store is a significant onboarding and maintenance burden for them, and we were genuinely hoping that a public OAuth app would give us a cleaner path to handle this at scale.

For Shopify Plus customers there’s a partial workaround – custom apps can be installed across multiple stores in the same Plus organization ( Select a distribution method ) – but that trades one problem for another. Not all of our customers are on Plus, and for those considering it, the cost of a Plus plan is a real consideration just to simplify a connector integration.

The security concern

Shopify’s documentation explicitly calls the client secret sensitive information and advises against exposing it outside of your own systems ( Using the client credentials grant ). The client credentials grant is also documented as being intended for “trusted, server-to-server integrations owned by your organization” and not for third-party SaaS platforms where one party is sharing credentials with another.

The custom app path asks our customers to share their client secret with us. We followed Shopify’s official documentation and went down the public app route specifically because it was the recommended path for what we’re doing. After weeks of back and forth through app review and now the dev community, the suggested alternative is to go back to square one and in doing so ignore Shopify’s own guidance.

Shopify’s move to expiring tokens was clearly a security improvement over permanent static tokens. But asking customers to hand a third party their client secret feels like it creates a different kind of security risk in its place. If the recommendation is to do exactly what the docs say not to do, that’s a gap worth closing.

The broader point

The current policy treats multi-source SaaS platforms the same as native Shopify apps, even when Shopify is just one of hundreds of integrations and no new customers are acquired through the App Store. We understand why the policy exists for Shopify-native apps. It just doesn’t map well to our use case.

You mentioned you’d make sure this feedback gets visibility with the relevant teams, and we really appreciate that. We’d genuinely love the opportunity to speak directly with those teams, walk through our use case, and provide whatever product feedback would be helpful. If there’s a way to make that connection, we’re very open to it.

Thanks again for your time on this.

10

@dmb Appreciate the detailed feedback, and I want to be upfront about where things stand.

You’re right that the custom app path asks customers to do something the docs explicitly advise against. The client credentials grant documentation describes the client secret as sensitive information that shouldn’t be exposed outside your own systems, but the workaround for your use case requires exactly that. I’ve captured that tension as formal product feedback internally.

The multi-store side of this is also a real limitation. Non-Plus merchants are limited to one custom app per store, so each of your customers’ stores means a separate app creation and credential exchange. Plus merchants can install a single custom app across stores in the same organization, but that only helps if your customers are on Plus.

I can’t set up a direct conversation with internal teams through the forum, but I’ve filed this as a product frustration with the specifics you’ve outlined here. That’s the mechanism that gives it visibility with the teams who own app distribution and billing policy. If anything changes that opens a better path for this use case, I’ll update this thread.