Migrating off of InAppProducts for subscription management in Play
Migrating off of InAppProducts for subscription management in Play
Everything you need to know about the new monetization.subscriptions APIs and 2024 migration deadline
Still not done migrating from InAppProducts to the monetization.subscriptions
APIs? RevenueCat’s Android and cross-platform SDKs are maintained to keep you ahead of Google platform changes. Move to RevenueCat today and save yourself the deprecation stress: Click here for our Android docs, or talk to us if you need help migrating
At Google I/O 2022 the Google Play Team unveiled one of the biggest updates to their in-app billing and subscriptions library yet: Google Play Billing Library 5.
With that new version of Play Billing Library (PBL), Google introduced a separation between what you sell (a subscription) and how you sell (a base plan and offers). At the same time, a new set of APIs to manage this new subscription structure was added to the Google Play Developer API: the monetization.subscriptions
APIs
As of January 1, 2024 new apps must use these monetization.subscriptions
APIs to manage their subscription catalog, instead of the InAppProducts API previously used, with a (very short) extension to May 1 of that same year for existing apps to migrate over.
In this blogpost, we’ll share:
- Everything you need to know about the
monetization.subscriptions
APIs; - Determining if the deadline affects you;
- An
inappproducts
tomonetization.subscriptions
migration guide; - An update on our support of the new APIs, and;
- A list of resources to help answer any remaining questions and support your migration
How the monetization.subscription APIs replace InAppProducts
Google’s monetization.subscriptions
APIs replace part of the InAppProduct API, which – historically – was used to manage the full product catalog for your application (the things you’re selling in the Play Store), encompassing both consumables / one-time purchases and subscriptions.
Doing this via API, rather then the Console UI, is useful in a number of specific instances, for example when there is a need to create a large number of unique subscriptions (to subscribe to individual creators in an app), or when an app does a lot of pricing and packaging segmentation and testing.
Going forward, inappproducts
is solely used to manage one-time purchases, while the monetization.subscriptions
APIs were introduced to manage the new subscription structure (subscription, base plan, and offer).
To manage these three objects, Google added three endpoints to the Google Play Developer API:
monetization.subscriptions
to manage subscriptionsmonetization.subscriptions.basePlans
to manage base plansmonetization.subscriptions.basePlans.offers
to manage offers
Managing subscriptions via monetization.subscriptions
monetization.subscriptions
is how your subscriptions are created and managed. Because a subscription can no longer be a single entity (it always includes – at least – one base plan), this same endpoint creates and updates additional base plans for your subscriptions.
The monetization.subscriptions
endpoint allows developers to list (list
), read (get
), create (create
), update (patch
), archive (archive
), and delete (delete
). In case of read and update, there are methods available to batch multiple subscriptions together: batchGet
and batchUpdate
Find a full overview of this new endpoint here, in Google Play’s Developer API docs
Managing base plans via monetization.subscriptions.basePlans
monetization.subscriptions.basePlans
is how you manage which base plans are active at any given time.
The monetization.subscriptions.basePlans
endpoint allows developers to activate (activate
), deactivate (deactivate
), or delete (delete
). It also allows for migration to a current price for users on legacy pricing (migratePrices
and batchMigratePrices
), or activate and deactivate multiple base plans together (batchUpdateStates
)
Find a full overview of this new endpoint here, in Google Play’s Developer API docs
Managing offers via monetization.subscriptions.basePlans.offers
monetization.subscriptions.basePlans.offers
is how offers are created and managed. It allows you to define both the specific details of an offer, as well as its targeting rule set.
The monetization.subscriptions.basePlans.offers
endpoint allows developers to list (list
), read (get
), create (create
), activate (activate
), update (patch
), deactivate (deactivate
), or delete (delete
). It also allows updates to multiple offers in one go (batchUpdate
), as well as activating / deactivating offers in bulk (batchUpdateStates
).
Find a full overview of this new endpoint here, in Google Play’s Developer API docs
When do you need to migrate from inappproducts to the monetization.subscription APIs?
The likelihood of this specific deadline impacting your app are slim, as you would exclusively use InAppProduct API to manage product catalogs remotely, without interacting with the Play Console UI.
This might be (but isn’t necessarily) the case if you see the following warning in your Google Play Console:
“You’re using the InAppProduct API to manage subscriptions, which is now deprecated and will stop being supported for new apps in January 2024, and for all apps in May 2024. Start using the new Subscriptions API to get new features including multiple base plans and offers, as well as prepaid plans.”
What this message means is that, prior to May 2022, you or someone working on your app used inappproducts
to manage subscriptions or one-time purchases. It does not mean that that is the case today:
When Google introduced PBL5 and converted all subscriptions to the new model featuring a single base plan and offer, it set all converted subscriptions to read-only in the Google Play Console. This is because once a converted subscription was edited in the Console, inappproducts
would no longer work for subscriptions.
If there are still read-only subscriptions in your Console, and you haven’t used monetization.subscriptions
yet, Play Console will assume that you might still use the InAppProduct API at some point. When you’re not using the API actively, you’re able to ignore the warning (and edit any of those read-only subscriptions).
If you’re on RevenueCat, you can ignore this issue: RevenueCat does not use the InAppProduct API for subscriptions. You are safe to make subscriptions editable and disregard this message, unless you or your team are using this API outside of RevenueCat.
If you’re part of a larger organization and aren’t sure if you’re using this API, check with your Android and / or platform team members.
Migrating to monetization.subscription from the InAppProduct API
Google converted your existing subscriptions to the new model:
These converted subscriptions mimic their original version by having a single backwards compatible base plan and offer, which the InAppProduct API has been able to manage as before the introduction of PBL5.
Because the new model introduces features and functionality that you (should want to, but technically) don’t have to use, we’ll focus on replicating the soon to be deprecated InAppProduct functionality with single backwards compatible base plans and offers via monetization.subscriptions
:
Using inappproducts | Using monetization.subscriptions |
packageName | packageName |
sku | productId |
status | basePlans[0].state |
prices | basePlans[0].regionalConfigs.price |
listings | listings |
defaultPrice | No longer available |
subscriptionPeriod | basePlans[0].autoRenewingBasePlanType.billingPeriodDuration |
trialPeriod | basePlans[0].offers[0].phases[0].regionalConfigs[0].free |
gracePeriod | basePlans[0].autoRenewingBasePlanType.gracePeriodDuration |
subscriptionTaxesAndComplianceSettings | taxAndComplianceSettings |
Replacing your existing inappproducts
references to point towards these objects under monetization.subscriptions
will allow you to switch over with a minimum amount of hassle.
One thing to keep an eye on is setting prices, which – previously – you could do via a single default price (through defaultPrice
), but now *has* to be set per region. The Play Console offers a handy ‘check all’ box for this purpose, but you must set regional pricing individually via the API for each country or region where you want to sell your product.
Note that this ‘basic’ migration mimics Play’s old subscription structure, and therefore doesn’t allow you to benefit from most of the new features and functionality as outlined in this post about Play Billing Library 5 (we’re now on PBL 6, but there are no noteworthy changes to how any of the above functions between 5 and 6).
Also keep in mind that you’ll continue using inappproducts
for one-time purchase management.
RevenueCat and Google Play’s subscription APIs
As pointed out earlier in this article, unless they built their own integration with the inappproducts
API, RevenueCat customers are unaffected by any of these changes. As one of our engineers pointed out in a Slack thread about this latest deprecation:
We’re always happy to chat about how we can keep you ahead of Google (and Apple)’s platform changes. Reach out to us here
Useful resources
Start with RevenueCat
Migrating your Android app over to RevenueCat will save you the trouble of figuring out support for new Google Play Billing Library versions and any future updates from Google and the other platforms. To start with RevenueCat, explore our migration guide docs. If you have more complex needs, we encourage you to request a custom migration plan from our team.
Resources from around the web related to inappproducts, monetization.subscriptions, and the Play Billing Library
- Managing subscriptions via Subscriptions Publishing API from the May 2022 new subscription features guide (link)
- Understanding subscriptions from the Play Console Help section (link)
- Play Billing Library release notes (link)
- About the Google Play Developer APIs (link)
Monetization.subscriptions
reference in the Google Play API docs (link)Monetization.subscriptions.basePlans
reference in the Google Play API docs (link)Monetization.subscriptions.basePlans.offers
reference in the Google Play API docs (link)- The ultimate guide to Android subscription testing
- An overview of Google Play Billing Library 5
You might also like
- Blog post
Implementing in-app purchases and monetizing your Roku app: A step-by-step guide
A comprehensive guide to implementing and monetizing your Roku channel, from choosing the right strategy to technical tips and integration best practices.
- Blog post
How we built the RevenueCat SDK for Kotlin Multiplatform
Explore the architecture and key decisions behind building the RevenueCat Kotlin Multiplatform SDK, designed to streamline in-app purchases across platforms.
- Blog post
Inside RevenueCat’s engineering strategy: Scaling beyond 32,000+ apps
The strategies and principles that guide our global team to build reliable, developer-loved software