- Create a RevenueCat account with a sandbox and non-sandbox environment
- Create an entitlement in each environment with the identifier of “Membership” in both
- Navigate to the interactive docs (or you can do this in your own code if you already have it set up) (https://docs.revenuecat.com/reference#basic)
- Enter your api key for your sandbox environment and pass any user id to create a subscriber https://docs.revenuecat.com/reference#subscribers
- Try to grant them a promotional grant for that user id, the entitlement identifier of “Membership” and duration of “yearly” https://docs.revenuecat.com/reference#grant-a-promotional-entitlement
- Returned subscription entitlement shows is_sandbox: false
Returned subscription info (see is_sandbox: false).
I can’t see what I’m doing wrong and this seems like a bug to me. I got memberships hooked up fine a year or so ago and am now adding in the ability to gift a membership. I have logic to check if sandbox flag is true when trying to process subscriptions in development and staging environments. This seems to be able to work fine in production but for testing I’d like the subscription to return is_sandbox true like the non-promotional subscriptions do.
Best answer by codyView original
It looks like the title was updated to not include the word Bug -- I’m pretty sure this is a bug unless it’s specified somewhere in the docs that is_sandbox returns false when in sandbox for promotional entitlement grants.
@REP! Sorry for the delay here, this got lost in our queue.
This is currently expected behavior- in RevenueCat, there is no concept of a sandbox user, only sandbox transactions, since a user ID can have both sandbox and production transactions associated with them. In this case, a promotional entitlement is considered to be ‘production’, and so the is_sandbox property is false. I’m going to add this to our backlog to improve our documentation around explaining this. Let me know if you have any other questions!
@cody -- thanks for checking it out! I totally understand that there’s no concept of a sandbox user, but the promotional entitlement comes back as a subscription which can be classified as a sandbox transaction and is in other cases. But it sounds like the entitlement grant is actually a part of the user and not technically a subscription even if it’s returned in the subscriptions array. We’ve already created a workaround in our code to handle this type of subscription for testing locally and in production, but I definitely wanted to flag it since the behavior was not consistent with the other subscriptions we’d integrated in the past.