You may also use the following legacy APIs, however these only support cookie authentication and not API key and/or OAuth 2.0 authentication, and are subject to change without notice. We do not recommend depending on these APIs as they may rely on needing to share cookies with application code that interacts with these endpoints. Please let us know the details of any use-cases you have which are not satisfied by the InventoryItem API and require these legacy APIs:
Query parameters: count (int), exclusiveStartId (long, last ID of the last game pass in the previous batch)
We’re committed to providing you with the best possible tools and resources, and these updates will help us deliver a more efficient and streamlined experience. Read more about other deprecated endpoints here.
Thanks for your continued support! Please comment and let us know if you have any concerns.
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?
Hi there 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?
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
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.
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?
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
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.
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):
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.
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.
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.
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.
Would it be possible to describe the ratelimiting of the Open Cloud 
