Will this be normalized more? The OpenCloud Asset API currently creates Decal assets which I have to then download using the AssetDelivery API and parse for the Texture property in external tooling.
Thankfully due to resources like Lune it’s less worse than it could be, but still feels unnecessary.
Yes, this is planned 
(words words words)
I’d argue it’d be the opposite since Decals can actually be archived, which also archives its underlying Image asset. Only being able to create Images would leave you in a situation where you might have a bunch of Images that you can’t hide on your creations page (under Development Items > Images), since there is no way to directly archive those.
As I mentioned before, archiving a Decal/MeshPart also automatically archives any underlying Image/Mesh assets that are included in the Decal/MeshPart. Both Decals and Images on the creations page have a “Show archived” toggle for a reason.
Supporting Decal/MeshParts as an option (not forced) would be fine - there probably are use cases where someone would genuinely prefer just having an Image/Mesh be created with no additional Decal/MeshPart, if they don’t care about being able to archive the asset and want to skip the extra step of having to call InsertService on the asset to extract an underlying Image/Mesh ID.
Having to call the API twice (as opposed to just creating a Decal from an EditableImage, with the Image asset being created automatically) seems a bit weird though, does this mean you would theoretically just be able to attach any random Image ID in your inventory to a newly-created Decal asset?
Absolutely love this update! Is it possible to be able to use the feature in Live experiences some time in the future? I know it might pose many risks (as it previously did before, when it was working for life experiences) but this feature can be super useful for experiences where users draw and create their own images
Thank you for the additional information! We’ll take some time to review this and reply with our conclusion.
I clearly have to better inform myself on the unique interaction between Decal/MeshPart assets and the referenced image/meshes; this seems like a legitimate use-case! It will also depend on what our longer-term plans are regarding archiving with the upcoming asset privacy changes.
CreateAssetAsync(editableImage, Enum.AssetType.Decal, ...) might be a valid way forward for this.
Thanks again!
The APIs in this announcement are explicitly not meant for in-experience, thus they will likely not be available in that context; however a different set of in-experience appropriate APIs that achieve a similar outcome are being worked on as mentioned to in the recent EditableMesh/Image announcement
Please take a look at the What’s Next section about Store plugins: [Beta] Lua Asset Creation for Creator Tooling with CreateAssetAsync
For this reason, plugins from the creator store cannot access the API, and we are working on features that will let users control which plugins can/cannot access the API, and review individual upload requests issued by plugins
Will functionality similar to what the sacred ThumbnailGenerator and CaptureService: CaptureScreenshot() provide ever be made available in “Cloud Luau Tasks”/Studio or even better live servers.
Functionality like this would be SO useful paired with CreateAssetAsync
This is actually already on our radar, albeit for other reasons. I can’t make any promises, but it’s something we’re considering trying to make happen in 2025. Thanks for the feedback and use case, that definitely helps us prioritize.
This is great. I already have plans to justify these APIs’ addition to the engine and further their value for creators on the platform. Well done.
With this API + being able to convert a camera or viewport frame into an editable image, I would be able to stop using expensive viewport frames in my UI to preview custom characters on small thumbnails. This would be a huge perf boost for me because I can have 20+ different characters in the UI at once. Would appreciate higher prio on this. I just need to take a snapshot of a viewport frame and upload the result with background transparency. That would be good enough and is honestly expected plugin functionality.
I have started rolling out a change to allow temporary images into EditableImage in the studio Edit DataModel. They still won’t be allowed in Play mode and for clients due to some privacy concerns with captures being put in EditableImage at runtime, but this should help with use cases for CreateAssetAsync!
What a cool plugin!! Yes, we’re super excited about the possibilities EditableMesh/Image open up for creator plugins. But we have to make sure we do it carefully.
Note that we are also investigating first-class Studio features for Editable* objects, which will, among other things, allow for the creation of assets from Editable*s through straight forward built-in UI.
If these features end up being good enough for you, your plugin might not even have to worry about creating assets for your users 
A long time ago there was talk about being able to publish models to players’ inventories from inside of an experience. I run a game about building, and my players are always asking for this export functionality. What’s the status on this? Is it still in the books or is it currently shelved?
To clarify, I mean Models. Not meshes. That thread is about Editables iirc.
Ah yes, I believe we briefly had a beta in-experience Model publishing API that we had to roll back for security reasons. That API is very much still planned and as far as I know will be the same API that support Editable* publishing from in-experience.
I believe you do, and I’m hoping this comes to fruition sooner than later as well. Would love to use it for in-experience publishing of EditableImages.
Thanks for being open with us regarding what the plans for the future are.
This method needs to be behind a prompt for each call, while I get why you’ve disabled it for cloud plugins (which is a from me for now), the risk is still there with local plugins if they’re just allowed to upload assets with no extra validation.
If the ultimate goal is to put this behind a plugin permission (or an evolution of that system), I still think we need a method to gracefully handle if a permission is granted or not. The current solution is to hackily use pcall to try and identify if the permission is given or not. This is especially an issue for methods that can fail for reasons other than a permission not being granted (ie HTTP).
