Rc Understanding Revenuecat

Understanding RevenueCat

Phase 0: Intent

Use this skill before writing any RevenueCat code. It gives you the vocabulary and mental model you need so that downstream skills (setup, configuration, purchase flow, entitlements) make sense.

Start here if any of these apply:

• You are new to RevenueCat or coming from a raw Play Billing integration.
• You are unsure which concept maps to which dashboard object.
• You need to decide which downstream skill to invoke for a specific user goal.

Skip this skill if you already know the difference between an Offering, a Package, a Product, and an Entitlement, and you already know that Purchases.sharedInstance is the single entry point.

Phase 1: Orient

Raw Android in-app purchases require three separate systems. RevenueCat folds all three into one SDK plus one dashboard.

The call path is:

Your App  -> Purchases SDK  -> RevenueCat Backend  -> Google Play Developer API  -> Google Play

Your app talks to the Purchases SDK. The SDK talks to Google Play for the purchase UI and to the RevenueCat backend for verification and entitlement storage. Your server side code talks to the RevenueCat backend, not to Google Play directly.

One consequence: RevenueCat sits in the purchase verification path. After a user completes a purchase, the SDK posts the token to RevenueCat before your app sees confirmation. You trade a network round trip for not having to build server side verification yourself.

The four concepts you must know

CustomerInfo is the runtime snapshot of the user's purchase history and active Entitlements, computed and cached by RevenueCat.

The only two reads you need most of the time

val offerings = Purchases.sharedInstance.awaitOfferings()val monthly = offerings.current?.monthly

val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()val hasPro = customerInfo.entitlements["pro_access"]?.isActive == true

isActive already resolves the seven Play subscription states (ACTIVE, IN_GRACE_PERIOD, ON_HOLD, PAUSED, CANCELED, EXPIRED, PENDING) on the server side. You do not reimplement that logic on the client.

The singleton

Purchases.sharedInstance is the single entry point. You configure it once at app startup:

Purchases.configure(    PurchasesConfiguration.Builder(context, "your_api_key")        .appUserID("optional_user_id")        .build())

Unlike BillingClient, the singleton does not require you to manage connection state. It reconnects and queues calls for you.

What RevenueCat does not replace

• Google Play Console. You still create products, base plans, and offers there.
• Your app UI. You still build the paywall and display prices. RevenueCat supplies the data.
• Your authentication system. You bring your own user IDs and pass them to the SDK.

The tradeoff

You offload verification complexity and take on a dependency. If the RevenueCat backend has an outage, purchase verification is affected. Two mitigations exist and they are different:

Neither is a full substitute for a reachable backend. Use both where they apply.

Phase 2: Map the user goal to a downstream skill

Once you have the model above, pick the next skill based on what the user actually wants to do.

If the user's goal does not match any row, stay here and keep clarifying intent before routing.

Phase 3: Sanity check

Before you leave this skill and route to a downstream one, confirm out loud:

1. You can name which of the three raw pillars (client billing, server Play Developer API, RTDN) the user's question touches.
2. You can state whether the user is asking about a Product, a Package, an Offering, or an Entitlement. These are not interchangeable.
3. You know whether the user needs Offerings (what to sell) or CustomerInfo (what the user already owns). Most confusion comes from mixing these two.
4. You have picked exactly one downstream skill to invoke next, or you have a concrete clarifying question.

If any of the four fail, reread Phase 1 or the chapter before proceeding.

References

• Full chapter