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.
Would it be possible to describe the ratelimiting of the Open Cloud 
