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.
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.
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?
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.
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!
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?
Unauthenticated asset loading ceased to work between 21:10 and 00:30 UTC.
USER@DESKTOP-0K06777 ~
$ date --iso-8601=seconds
2025-04-03T05:57:23+00:00
USER@DESKTOP-0K06777 ~
$ curl https://assetdelivery.roblox.com/v1/asset/?id=4794911592 -L
Warning: Binary output can mess up your terminal. Use "--output -" to tell curl to output it to your terminal anyway, or consider "--output <FILE>" to save to
Warning: a file.
USER@DESKTOP-0K06777 ~
$ curl -s https://assetdelivery.roblox.com/v1/asset/?id=4794911592 -L --output - | wc --bytes
8929238
Unauthenticated asset loading also worked as of 07:03 (past midnight Pacific).
USER@DESKTOP-0K06777 ~
$ date --iso-8601=seconds
2025-04-03T07:03:28+00:00
USER@DESKTOP-0K06777 ~
$ curl https://assetdelivery.roblox.com/v1/asset/?id=4794911592 -L
Warning: Binary output can mess up your terminal. Use "--output -" to tell curl to output it to your terminal anyway, or consider "--output <FILE>" to save to
Warning: a file.
USER@DESKTOP-0K06777 ~
$ curl -s https://assetdelivery.roblox.com/v1/asset/?id=4794911592 -L --output - | wc --bytes
8929238
root@localhost:~# date --iso-8601=seconds
2025-04-03T19:10:29+00:00
root@localhost:~# curl assetdelivery.roblox.com/v1/asset/?id=1818 -L
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
Still as of 21:10Z.
USER@DESKTOP-0K06777 ~
$ date --iso-8601=seconds
2025-04-03T21:10:58+00:00
USER@DESKTOP-0K06777 ~
$ curl https://assetdelivery.roblox.com/v1/asset/?id=4794911592 -L
Warning: Binary output can mess up your terminal. Use "--output -" to tell curl to output it to your terminal anyway, or consider "--output <FILE>" to save to
Warning: a file.
USER@DESKTOP-0K06777 ~
$ date --iso-8601=seconds
2025-04-04T00:35:40+00:00
USER@DESKTOP-0K06777 ~
$ curl https://assetdelivery.roblox.com/v1/asset/?id=4794911592 -L
{"errors":[{"code":0,"message":"Authentication required to access Asset."}]}
Well now what do i do? i was using assetdelivery for getting the binary by http service and roproxy and then i get some data from it but now i cant access it
Hi unmiss. Have you tried just making a “user” API key? It just wants to verify you are a valid user making the request. So far, it does not seem to care which user creates the key. The new assetdelivery returns a “location” URL to which you must send another http GET to retrieve the binary.
Unfortunately, the new API does not contain the image id anywhere in the response, only the actual image binary location. I refuse to use a cookie to authenticate my requests, given how fickle they are.
Either add a dedicated “get image id from decal id” endpoint, or allow us to use user keys to access the legacy apis.
