Apple seems to have fixed this as we mostly stopped getting the error 5 hours ago.

We've been getting 500000 from one of our apps when calling the subscription status GET API in the sandbox environment since about 10 hours ago. GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/subscriptions/{originalTransactionId} Production environment seems to be unaffected at the moment. Nonetheless seems like a problem on Apple's end?

Thanks. I've filed a ticket FB11989240 with a sample from our sandbox environment.

After a bit more testing I'm going to answer myself on a couple of things. setting extendByDays to 90 days seems to extend the subscription by 38 minutes in Sandbox. resetting introductory offer eligibility through Settings also seems to reset the twice a year limitation. It would be great if I can get a little more detail on when "success = false".

Thanks for the reply! Now I have a few more questions. Is it possible for you to briefly explain or point me in the right direction how sandbox scaling works in this instance? Is there a way to reset the twice a year limitation in sandbox, like the ability to reset introductory offer eligibility? when I exceed the twice a year limitation and call the API again, is it correct to assume that I will get a 200 response with the body of a previous extension attempt? since from my observation "success" always seems to be true in the body.

Thanks, just sent in a bug report. It's been two weeks since I submitted this to the feedback assistant but there's still no response from Apple.

Here is a sample of the notification exhibiting this bug, but like farias said there is no way to know which subscriptions are associated. { "notification_type": "DID_RENEW", "password": "********************************", "environment": "PROD", "auto_renew_product_id": "xxx", "auto_renew_status": "true", "bid": "xxx", "bvrs": "xxx" } We have a batch that calls verifyReceipt to ensure subscription validity so this does not present a huge problem for us but I'm sure we'd all like t see this fixed.

Thanks, just sent in a bug report. FYI it is still happening in our production environment.