I confirmed that read_own_subscription_contracts only gives access to contracts owned by the calling app, so a non-subscription app can’t read contracts created by Shopify Subscriptions or another subscription app.
My use case is not billing or contract management. I only need a reliable current subscription-state signal for customer segmentation / lifecycle automation.
Order-level selling plan data is not enough because it tells me purchase mode at checkout, not whether the customer’s subscription is still active now.
What is the recommended supported pattern for this use case?
Is there any Shopify-recommended app-agnostic pattern here, or is per-subscription-app integration the only path today?
Hey @panos_supersell_club 
You’re right,. read_own_subscription_contracts is scoped strictly to contracts your app created, and there’s no broader Admin API scope that gives cross-app visibility. Subscription webhooks (subscription_contracts/create, /update, /cancel, etc.) follow the same ownership model, so a non-subscription app won’t receive events from Shopify Subscriptions or any other subscription provider.
If you’re building on Hydrogen or a Headless storefront, the Customer Account API has a customer_write_subscription_contracts scope that provides access to all subscription contracts regardless of which app created them.
For the Admin API path, the most practical pattern is using Shopify Flow as a bridge. Flow has “Subscription contract created” and “Subscription contract updated” triggers that fire for any subscription app, including the 1P Shopify Subscriptions app. The “updated” trigger fires on status changes (active, paused, cancelled), so you’d add a condition checking the contract status and then use the “Update customer metafield” action to write something like custom.subscription_status. Your app can then read that metafield with the read_customers scope. It requires the merchant to set up the Flow, but it does get you a near-real-time, app-agnostic subscription states.
I covered this same limitation in a similar thread where the workarounds are discussed in more detail.
1 Like
Hi Donal,
The Flows workaround sounds promising although a clear solution would be nice if it was added to the roadmap. I will look into it.
Thank you so much.
1 Like
Could I create this flow via an API instead of forcing the merchant to create it?
Unfortunately not, the fact that merchants have to create the flows are the reason they’re able to see all subscriptions and act as this bridge. It’s an imperfect workaround, but this is by design.
1 Like