MarketplaceService:GetUserSubscriptionDetailsAsync() does not support test subscription IDs

Bug Reports Engine Bugs
,
1

MarketplaceService:GetUserSubscriptionStatusAsync() works, but MarketplaceService:GetUserSubscriptionDetailsAsync() does not.

e.g. with the following server-side code

game.Players.PlayerAdded:Connect(function(Player)
   print("A", game:GetService("MarketplaceService"):GetUserSubscriptionStatusAsync(Player, "EXP-0"))
   print("B", game:GetService("MarketplaceService"):GetUserSubscriptionDetailsAsync(Player, "EXP-0"))
end)

I get an HTTP 500 (Internal Server Error) from the second API call when running it in Studio.

2

Found someone to look at this! We’ll get back to you when we have an update.

1 Like
3

Hi, thanks for letting us know! We are aware of this and will be working on adding the ability to use a test subscription ID for the new GetUserSubscriptionDetailsAsync() endpoint soon.

1 Like
4

Can you please provide following information:

  1. player id/name
  2. experience id
  3. which developer subscription product, or subscription id

thx

5

This is for any player using any of the four testing subscription IDs in any experience e.g. EXP-0 through EXP-4 as documented here (MarketplaceService | Documentation - Roblox Creator Hub)

For EXP-0, I get HTTP 400 (bad request). For EXP-1 through EXP-4 I get a valid response as if I had provided a real subscription ID (rather than one of the testing IDs). All of EXP-0 through EXP-4 should be treated as testing IDs.

6

Mock subscription ids are only supported by these 2 APIs.

  • MockMarketplaceApiClient::getUserSubscriptionPaymentHistoryAsync()
  • MarketplaceApiClient::getUserSubscriptionStatusAsync()

MarketplaceApiClient::getUserSubscriptionDetailsAsync() does support that.

7

Yes, that is simply restating the title of this topic. The issue is that, because test subscription IDs are supported by some subscription APIs, I as a user expect those test IDs to work for all subscription APIs. If this is not the case then it makes it harder for me to test my game because I can’t properly test the APIs and have to special-case my testing code.

For example, something I do for testing is globally overwrite subscription ID setting to a test subscription ID so I can see what happens in my game when a subscription is in a particular state.

MyGameSettings.SubscriptionId = "EXP-2" -- testing refunded subscription

But this would no longer give expected results if I happen to use an API like GetUserSubscriptionDetailsAsync() in my game somewhere.

I actually have a game where I added support for using GetUserSubscriptionDetailsAsync() (rather than the older ways of getting info about a subscription), but then disabled that support, because it didn’t play nicely with test IDs. It just wasn’t worth the effort to use this new API if I couldn’t test it properly.

In the past your colleagues seem to have recognized this issue and said they were going to fix it, but I don’t know what has happened with that: