Test store renewals - API returns empty entitlements momentarily in between renewals

Hi Abhi,

Thanks for raising this. The test store transaction do indeed have simplified renewal logic where it waits for after the expiration to create the renewal. For production transactions, the API should absolutely be reliable for checking entitlements.

However, since we certainly want the test transactions to give the most accurate simulation possible, I will check with engineering to see if we can improve this experience.

I’ll let you know when I learn more.

Cheers,
Debbie

Hi Debbie,

Thanks, that makes sense. I was wondering if I had to design a solution to handle this case. No need then, I guess.
So, what I understand is that entitlements won’t be empty in between renewals on Production. I will build according to that.

Thanks again,

Abhi
 

Sounds good! I’ll update this thread if anything changes on our end, for future reference.

Cheers,
Debbie

One production note to complement the answer above, since this exact area bit us after we moved past the Test Store: even in production, I’d avoid letting a single point-in-time poll of active entitlements be the thing that cuts off access. Around billing retry / grace period an expiration can be followed by a recovery, and if your backend hard-revokes on the first empty response, the user loses access mid-recovery.

The pattern that has been reliable for us: treat webhooks as the source of truth for state changes (EXPIRATION, BILLING_ISSUE, RENEWAL, UNCANCELLATION), store the last known expiration date server-side, and only revoke once that date passes with no renewal event — plus a small buffer. The v2 active-entitlements endpoint then becomes a reconciliation check rather than the gatekeeper. It also helps to enable grace period / billing retry in the store configs so the recovery events exist at all.