Google Play rejection — how can I give reviewers free Pro access with anonymous RevenueCat users?

Offering Metadata can control a flag your app already handles, but the metadata is readable through the SDK. It won’t identify Google reviewers or keep an access code secret.

Promotional entitlements need a specific App User ID. A manual grant works once you know that ID, but not for an unknown reviewer’s fresh install. Anonymous IDs can also change after reinstalling.

For automatic grants without a shared customer ID, one option is a small serverless endpoint that validates a reusable reviewer code and grants Pro to that installation’s current RevenueCat App User ID using the grant API. Keep the RevenueCat secret API key on the server. That still needs a backend component; Offering Metadata alone cannot securely validate the code.

One important catch: Google’s requirements explicitly cover apps with no login but a subscription paywall. Add clear instructions under App access and keep the reviewer access working for future reviews, rather than switching it off after approval. They require reusable access available at all times. This setup isn’t a guarantee of approval.

Thank you so much for your detailed explanation — it`s very helpful!

I'm considering a hidden access-code option that would grant Google reviewers 30 days of complimentary Pro access through RevenueCat, with automatic expiry.

The code itself would remain valid for future reviews, and I'd be able to change it when necessary.

Do you think this would satisfy Google's review requirements? And is there anything I should watch out for with repeated redemptions or entitlement expiry?

Thanks again for your help!

I wouldn’t treat a 30-day grant as a guarantee of approval. Google requires reusable review access available at all times. If you use an expiry, make sure reviewers can redeem again after it expires, on the same installation and on fresh installs. Keep the code working and explain exactly how to reach the code-entry screen in App access.

RevenueCat promotional grants expire automatically and don’t turn into paid subscriptions. Use an explicit end_time_ms for the expiry. Repeat grants don’t simply stack another 30 days: later grants can extend access to the latest expiry, and the grant API treats requested expiry times within two hours of an active promotional grant’s expiry as duplicates.

Keep code validation and the secret API key on your server. Make retries safe without making the reviewer code single use. After a successful grant, invalidate the CustomerInfo cache, fetch CustomerInfo again and unlock based on the active Pro entitlement.

Before resubmitting, test redemption while access is active, after it expires, and on a fresh install with a new anonymous ID.

Thank you so much!

Hi ​@julia-reeve ,

I'm Tarek from RevenueCat Developer Support, thanks for reaching out and for the clear write-up, happy to help!

I looked into this. I think you can solve it with an access code, a granted entitlement and Purchases.logIn(). You need no backend, and you can switch the access on and off in the RevenueCat dashboard, with no new build.

Is there a RevenueCat-native way to provide Google reviewers with complimentary Pro access when their anonymous customer ID isn't known beforehand?

RevenueCat cannot detect a reviewer automatically. But you can make the access code an App User ID. You grant Pro to that App User ID, and the reviewer device logs in with it. I recommend these steps:

1. Create a long random code, for example a UUID. Our docs explain that App User IDs should not be guessable.
2. Add an "Enter access code" button for users who have no active entitlement.
3. When a user enters a secret code shared with Google reviewers, call Purchases.logIn(code).
4. Enter the code once in your own app. This creates the customer in RevenueCat.
5. In the dashboard, grant the Pro entitlement to that customer, with an end date after the review.
6. In Play Console, go to Policy and programs → App content → Sign-in details.
7. Add the steps and the code in the "Any other instructions" field.

Here is a short example for React Native. You can replace pro with your entitlement identifier:

const { customerInfo } = await Purchases.logIn(code.trim())
if (!customerInfo.entitlements.active["pro"]) {
  // Wrong or expired code: go back to an anonymous user
  await Purchases.logOut()
}

With a wrong code, logIn() creates a new customer with that code as its ID. That is why the example goes back to an anonymous user.

Could RevenueCat Offering Metadata be used to enable/disable reviewer access remotely?

Yes, you can use it as a switch for the button. For example, you can add "show_access_code": true to the metadata of your current offering. Your app then shows the button only when the value is true.

The SDK caches offerings for up to 5 minutes, and it does not keep them between app launches. So the app gets your change within 5 minutes, or at the next launch.

The grant is still the real switch though. When the grant ends, or when you remove it, the code does not unlock Pro anymore.

Is there a secure way to implement an access code without exposing it in client-readable metadata?

Yes, the App User ID approach does this. The code is not in your app or in the metadata. The entitlement is on the customer in RevenueCat.

The metadata is not a safe place for a code. The SDK downloads it with your public API key, so any user of your app can read it.

Anyone who knows the code gets access, like a demo password. So I recommend that you use a new code for each review.

Could promotional entitlements be granted automatically to reviewers without linking them to a shared RevenueCat customer ID?

This is not possible without a server. A granted entitlement always belongs to one App User ID. An automatic grant needs our REST API and a secret API key.

Our docs say that a secret API key must only be on your own servers, never in your app. Also, you cannot know an anonymous ID before the review.

So a shared App User ID is the simplest option without a backend. Each device that logs in with that ID gets the same entitlement.

Has anyone successfully solved this particular Google Play rejection, and what approach did Google accept?

I can't speak for Google's review team, and I can't promise a result. Google's Sign-in details guide asks for the access details when a membership or another restriction blocks part of an app.

In the "Any other instructions" field, I recommend that you explain that the app has no accounts. You can also say that the code unlocks all premium features with no purchase.

One more tip: if you also ship on iOS, I recommend that you show the button on Android only. Apple reviewers test purchases in the sandbox at no cost. That's because Apple's guideline 3.1.1 does not allow apps to unlock features with their own codes, such as license keys.

Let me know if that makes sense and if there's anything else I can help with!

Have an excellent day.

Best regards,