Provide a stable Open Cloud API to get an image ID from a decal ID

Feature Requests Website Features
1

As a Roblox developer, it is currently too hard to upload images using the Open Cloud Assets API and get any use out of them. It returns a Decal ID which is effectively useless.

The asset delivery API used to accomplish this goal, but this API is failing for a number of users and/or returning data we can’t use.

There are other legacy APIs that do exist, but they require cookies. Not fun!

Please provide an API that lets us accomplish this goal. Or, alternatively, modify the Open Cloud Create Asset API to include an image ID that we can actually use!

If Roblox is able to address this issue, it would improve mine and many others’ development experiences who use Asphalt, an assets-as-files tool for Roblox (a modern version of Tarmac). This tool has become broken due to Roblox’s recent changes, and is impacting our daily workflow.

Edit 1:
It appears the legacy-asset:manage scoped API key can be used with the new assetdelivery API. But that API key scope cannot be used for groups.

In the meantime, Asphalt has reverted to using cookie-based authentication for grabbing image IDs :frowning:

30 Likes
2

Some time back InsertService was opened up for Decals. This allows to get the image id from the decal id. More Information: Non-sequential Asset ID Generation Coming Soon. Does this address your need ?

3

This does not. OP is referring to external tooling, separate from Roblox engine scripts.

Here’s the issue as it stands right now:

We need a way to simply request the image id without any workarounds.

1 Like
4

Nope! This is a CLI tool, similar to Tarmac.

5

Decals are an RBXM file pointing to the texture ID through a single Decal instance, is this approach feasible:

  • Download the asset id (which itself is USUALLY an XML RBXM (but might be binary))
  • Parse the XML stream
  • Fetch the created Decal’s texture ID

I get the point of this feature request is so you dont have to do that, and I definitely think this should be the case, but I’m just giving a workaround until then.

6

not possible with the new authenticated api, it just gives you a link to the actual image binary

7

It is, sort of, and it’s what we’ve done for a while. But Roblox has guarded that API (assetdelivery) behind either cookie authentication (which we don’t want) or the legacy-asset:manage permission scope, which is unavailable to groups.

I do not see any privacy concerns with providing all Creators with the ability to get an image ID from a decal ID. We don’t need to download the image, we just want the ID. It’s up to the Creator to make sure they have the correct permissions. The decal ID does not serve us any purpose. The Asset Create API, in my opinion, should be extended or adjusted to reflect that goal.

8

Please @Roblox Fix this issue so that game devs have an easier time uploading assets without providing so many keys. Especially since you guys want to improve your API please make it actually better instead of requiring MORE.

9

I genuinely wonder why we have to jump through so many hoops to get the usable image ID of a Decal after uploading it. This creates unnecessary friction for developers building automated pipelines or external tools, especially when handling large volumes of assets.

In my case, I’m developing an external asset management system for a 2D character customization game, and I’ve encountered two significant pain points:

  1. Scalability with LoadAsset: I’m managing a database of over 50,000 and more image assets. I’m concerned that relying on InsertService:LoadAsset at runtime will not scale well, both in terms of performance and API rate limits. It would be far more efficient if I could retrieve and store the actual image asset ID immediately after publishing (via the external database), rather than reprocessing the same asset repeatedly during gameplay.

  2. Inconsistent rbxassetid:// behavior: In Studio, using rbxassetid://{decalId} often resolves correctly when assigned to ImageLabel.Image. However, this behavior does not carry over into runtime. I’m unclear why there is a discrepancy between Studio and runtime resolution, and this adds further complexity for automated systems.

Currently, the only reliable workaround I’ve found is to use the legacy asset delivery API (along with individual account keys) to parse the XML and extract the actual <url> for the image. But this raises further questions:

  • Why isn’t this functionality part of the modern Assets API?
  • Is this legacy API expected to remain supported, or will it be deprecated?
  • Will we need to develop even more workarounds in the future to achieve the same result?

It would be incredibly helpful if the Assets API could return the final usable asset image ID directly in the upload response, or at least provide a supported, easier method to resolve Decal IDs to usable image asset IDs.

1 Like