Use this skill when managing the Android product catalog through the Play Console and the RevenueCat dashboard. Covers the two sided catalog flow (create in Play Console, import or map in RevenueCat), entitlement and offering maintenance, and why you do not call the Google Play Developer API directly.
72
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Manage the Android product catalog across two surfaces: the Google Play Console (source of truth for products) and the RevenueCat dashboard (entitlements, offerings, targeting). You do not call the Google Play Developer monetization.subscriptions or monetization.onetimeproducts endpoints from your app or backend.
Read this phase before you touch anything.
| Surface | Owns | Examples |
|---|---|---|
| Google Play Console | Underlying products, base plans, offers, prices | premium_monthly, base plan p1m, intro offer |
| RevenueCat dashboard | Entitlements, Offerings, Packages, Targeting | pro entitlement, default offering, $rc_monthly package |
Play Console holds the billable SKU. RevenueCat decides which SKU gets surfaced to which user and under which entitlement key.
When your app calls awaitOfferings(), it fetches whatever the RevenueCat dashboard has configured. Offering edits, package swaps, and targeting rules propagate on the next app launch. No binary release is required.
If you need to automate catalog edits from a backend (for example, seeding dozens of offerings across environments), use the RevenueCat REST API for products, entitlements, and offerings. You still do not talk to Google directly. Play Console remains the product source of truth.
Before you make a change, decide:
$rc_monthly, $rc_annual) so your paywall code keeps working.The end to end flow for adding a new subscription product.
premium_monthly), name, and description.Wait a few minutes for Play to propagate the product.
pro. Every product that unlocks pro features attaches to pro.Your client code checks entitlements by key:
val isPro = customerInfo.entitlements["pro"]?.isActive == truedefault).$rc_monthly for monthly$rc_annual for annualYour client code stays the same:
val offerings = Purchases.sharedInstance.awaitOfferings()
val monthly = offerings.current?.monthlyIf different users should see different offerings, use placements.
paywall_upsell).Client code:
val offering = offerings.getCurrentOfferingForPlacement("paywall_upsell")
?: offerings.currentNo app update is required when you change targeting rules later.
Check the change landed before you close the task.
| Check | How |
|---|---|
| Product exists in Play | Play Console -> Subscriptions shows the product as Active |
| Product imported to RC | Dashboard -> Products lists the product |
| Entitlement mapping | Dashboard -> Entitlements shows the product under the right entitlement |
| Offering wiring | Dashboard -> Offerings shows the product attached to the expected package |
| Runtime fetch | Launch the app, call awaitOfferings(), confirm the package resolves |
| Entitlement unlock | Complete a test purchase, confirm customerInfo.entitlements["pro"].isActive is true |
If awaitOfferings() returns null for a package you expect, the most common causes are: the offering is not marked Current, the product is not attached to the package, or Play has not finished propagating the product.
monetization.subscriptions from your backend. Use RevenueCat instead.offerings.current will see the old offering until you flip this.ccfc038
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.