this utterly nukes the quality of the image and is not a viable solution
You should be using game:GetObjects for this since its looser in its restrictions. Please do not use LoadAsset in plugins, its horrible.
Is there plans for a open cloud alternative for the batch endpoint?
We have functionality that fetches numerous assets at once and I’d imagine we’d quickly hit rate limits calling the new endpoint for each individual one.
2 Likes
Can’t they just do the blocked operation in a published experience, and download the asset using an exploiting client?
That’s my immediate thought of a simple bypass.
You’ve probably accounted for that is my guess…
I tested, and as long as your are logged in the browser (aka having a User Cookie on your browser), you can use the classic endpoints.
Are public assets such as decals, accessories and the like going to need authentication?
Yes. Even “public” assets will require an authenticated request. This change won’t break any experiences as all gameplay and studio usage is done while authenticated. This will mainly affect creators making calls to asset delivery outside of experiences (for example: from a browser extension, or through a proxy)
Is there a way to even test this?
We’re monitoring all unauthenticated requests right now. If you have any questions about a specific place or asset we can check if it’s in our list and let you know.
And one week is way too short. It should’ve been 2 weeks.
We hear you. We try our best to give our creators ample time to make changes, but some changes must be implemented quickly for security. That said, this feedback is being shared with the team. We appreciate your understanding.
1 Like
We’re targeting 3PM PST - we’ll post if there are any updates
1 Like
My main concern here is user-facing third-party tools and rate-limits. Requiring a user to enter their cookie for a service would be absolutely horrific for security and the alternative of requesting an API key / oauth token is not only also inconvenient, but it still also requires the user to have a Roblox account (which mightn’t be the case for third-party websites, plus the fact that some accounts may be <13 and unable to authenticate via oauth to view public assets). This also makes the assumption that the user would be willing to give what could presumably become full asset management permissions on their account to us, aswell as presumably gaining access to any private assets they may have on their account. 
All the legacy OpenCloud APIs have taken too broad of a view on scopes. Rather than separating read and write permissions, both have become essentially the same scope. This has led to significant difficulties with designing my application to only use the scopes it needs, I essentially am forced to ask for way too much permission for lack of an alternative. For example, I recently wanted to use oauth to list whether someone has game edit access; I was turned off the idea once I found out that the scope for doing so was also shared by the endpoint for making experiences public/private, something my application does not need and a hefty permission for any developer to consider giving a third-party website.
Using a backend for the requests isn’t really an option either, because I can only assume API keys have extra rate limits. Per-account cookie rate limits would presumably require us to scale in multiple alt accounts as our service grows to handle more traffic, not a very scalable solution. API keys also aren’t exactly ideal since they can’t scale like our services can, and managing the distribution across multiple keys / accounts is a significantly complex task. A lot of developers are already required to rotate IPs for bigger services, and rotating accounts / keys is another unfortunate roadblock.
I understand that this was presumably done to prevent scraping, but the alternatives don’t match the needs of third-party tools just yet. I’m not even sure if there is a perfect solution here, and to clarify, I mean no offence to the team in this. I just thought I’d raise my personal concerns here, just in case others share the sentiment.
2 Likes
This API is core to my workflow when working on big projects where you don’t always know where an asset comes from. It’s nice to be able to, for example, download an image an artist who left the company made, desaturate it, then re-upload it as a white image that can be recolored in engine.
Adding an authentication requirement will complicate some memory usage auditing tools I have in place.
Realistically this change is fine in the long run, it would just be nice if Roblox provided official tools for downloading assets in a game, rather than making the developers do this ourselves. It would likely take me a good few days to do a project like this, and in my free time when i am working on Roblox games full time.
1 Like
Go back and read what I wrote… I am using LoadAsset from the command line. I do not write plugins.
1 Like
As long you are logged in on the browser will you still be able to use asset delivery via URL in that browser? Also, will browser extensions such as BTRoblox will still work as long as you are logged in? (As it uses a asset delivery URL to download assets, and if a user cookie is valid, then it should work, right?) Also this doesn’t help secure creator content that well, as people can just insert service a hat for example and then download the obj, meaning UGC stealing will still be prevelant (unless you guys actually do something about that). And if you can still do it in a browser with a User Cookie, you can grab audios and decals that way. What is this protecting creator content from, exactly?
1 Like
The transition was relatively straightforward!
My only annoyance is that it seems to be forcing a JSON response for the /v1/* endpoints now, where-as before it would always give you an application/octet-stream response. Even when I set the Accept-Encoding header, it still sends me a JSON response.
I thought that was the main difference between /v1/ and /v2/, but I might be wrong.
1 Like
Yes, we are excited to be enhancing our asset privacy & permissions features soon. The upcoming beta launch will include workflow improvements and give creators the option to enable privacy for meshes and images! With the change announced today, all requests to Asset Delivery APIs will need to be authenticated. It will not impact permissions for authenticated users to access assets. For some asset types (e.g. audio, video), we already require permissions for the authenticated user or experience to access a particular asset. As we mentioned here, we’ll soon be broadening this access control to more asset types. Stay tuned for the asset privacy & permissions announcement in the next few weeks!
2 Likes
My extension literally uses this API thousands x2 of times for each page so if rate limits even get added I’m going to have so much problems 
No understanding from me, you literally provided no explanation as to why you’re doing this.
Thank you, finally I’ve been waiting for this update for so long.! I’ll have some few additional questions in PMs.
1 Like
except they did…
These endpoints currently allow unauthenticated access to many assets. We’re making this change to enhance security and prevent abuse of creators’ content, including unauthorized content scraping. This update will allow us to protect your content better and provide a more secure platform.
It seems like that projects using the old roblox client contributed the cost, as outside this platform, there is Roblox Revival that mostly use the V1 endpoint.
We’re monitoring all unauthenticated requests right now. If you have any questions about a specific place or asset we can check if it’s in our list and let you know.
As I noticed, you have been planning to work on this API change for months, because it only started to affect unauthenticated requests back in November 2024 with the rate-limiter. Many users found out that using authenticated cookies would bypass the rate-limit, and so on it improved it.
One question it still remains is that this feature was announced due of the overloaded requests, right?
I don’t really get the point
I don’t see how this is even a problem (very vague on how you can abuse someone public assets), and adding an authorization won’t fix anything.
for example in the case of “scraping”, people can just make roblox accounts, get their cookies/oauth and boom it works…
1 Like