Deprecating a Legacy Inventory API

This topic was automatically opened after 10 minutes.

Good to know; excuse my ignorance, I haven’t done cloud development / (anything that generally utilizes use of this, generally) for quite some time now – are there any main differences in legacy API compared to V2?

21 Likes

I made this feature-request a while ago about a missing parameter only present on the legacy APIs, would be appreciated if this could be looked into:

26 Likes

Hi there :slightly_smiling_face: Would it be possible to describe the ratelimiting of the Open Cloud /cloud/v2/users/{user_id}/inventory-items endpoint, or any approximations? And does the endpoint get ratelimited by IP or by API key?

15 Likes

Wanted to +1 what @abcreator said - a missing use-case is returning the time a user obtained an item. I’ve built a few applications in the past that deal with the collection and aggregation of user inventory data in order to create statistics for a few different datasets. I’m currently building out an on-platform experience for this (images below).


Currently, I need to ask my users to make their inventories public - and then query the legacy inventory API in order to get the time the user obtained their items (created field). The Open Cloud variant doesn’t provide any timestamps regarding when the user obtained an item, and the AvatarEditorService:GetInventory method can’t be used as it’s entirely client-sided and thus would harm the integrity of the experience (in context of things like leaderboards and overarching statistics).

Allowing us to query this information through Open Cloud APIs would give users a safe way to allow our experiences to collect their inventory data without having to expose anything, and give developers a reliable and secure (as in: integrity is kept) way of getting this data :pray:

P.S. Thank you for the continued heads-up about deprecated endpoints & when y’all are going to kill them! Even if some don’t see much traffic nowadays, it’s still awesome to be getting updates all these years later.

25 Likes

Are there any specific plans to implement support for API key or OAuth 2.0 authentication in the legacy APIs (Inventory API v2, Badges API v1, and Game Passes API), or will they remain dependent on cookie authentication indefinitely? Additionally, how can developers provide feedback on specific use-cases that are not covered by the new InventoryItem API?

11 Likes

Interesting change, wondering where this will lead us!
I Do agree this was a needed change, although you must be careful to not hurt businesses like Rolimons
image

18 Likes

If you used the old one, will it still be able to work?

9 Likes

We’ve generally focused on incorporating the legacy APIs’ functionality into OpenCloud v2 resources. However, we understand that necessitates more code changes for any scripts you have built on top of the legacy APIs already, vs. just swapping out a cookie for an API key and changing the URL.

We did pretty much what you described for a few APIs at the end of last year! Legacy overview | Documentation - Roblox Creator Hub

We have plans this year to:

  • Accelerate the pace of providing API options that don’t need cookies
  • Improving the reference documentation so it’s easier to find API endpoints and understand which auth methods they support
8 Likes

Thanks @Abcreator and @green271 - we’re looking into how we can support this for all item types in the InventoryItem API and will follow up here.

14 Likes

Hi, the legacy inventory API is the only way to get inventory stuff without an API key and it tells me to use the www api instead, is this normal?

1 Like

When will there be a way to make API requests directly to Roblox, without needing a proxy or keys? We already have limited access via things like the MarketPlaceService. When will we get services like this for all types of data such as public experience data, inventory data if made public, and basically everything that’s publicly accessible via normal endpoints? I don’t really understand why Roblox continues to limit this when services already exist in limited capacity that already prevent spam.

This one post from 2023 still gives me hope, but it’s now 2025 (expand for the reply message):

2 Likes

I’m pretty sure he was referring to Roblox planning to remove the blocks on their own APIs in HttpService. This feature was unfortunately scrapped due to technical complications, from what I can recall.

1 Like

Would you happen to have a post talking about that? I also don’t understand what technical complications they might be referring to, especially when there are examples of them making it work. But I’m assuming it would have to be something less obvious than what I’m thinking of, otherwise I don’t see the issue.

1 Like

people could make roblox games that send a denial of service attack to their own servers

Roblox controls these limits. This is why I linked the MarketPlaceService, because it does exactly what I’m asking for and is rate limited. This definitely isn’t an issue of DOS. Which is why I assume that it’s due to some other reason, but I wish Roblox were transparent about it. Otherwise it seems like it wasn’t dropped for a good reason.

All I’m asking for is more services like that, and ideally for all endpoints eventually.

We’re aware of the interest to hit Roblox endpoints via Luau (HttpService or similar) and we have someone actively looking into this again as of recently. No timeline for shipping a solution yet but wanted to let you know there is active effort on this topic.

4 Likes

I’m so aware that the Old Features would’ve been Removed for compensation with New Features…

Hello, thanks for your feedback!

For the Open Cloud /cloud/v2/users/{user_id}/inventory-items endpoint, we have documented the rate limits here: InventoryItem | Documentation - Roblox Creator Hub.

Rate limits:

  • For API keys: 100 requests per minute per API key owner. The owner can be a user or a group. Rate limits are enforced across all of the owner’s API keys.

  • OAuth2 tokens: 20 requests per minute per OAuth2 access token.

Hope that helps!

1 Like

Thanks a bunch! I’m glad it got written in the documentation as well :+1: