API Method to easily get the properties of an object

Hang on, so now this topic is about improving API dump, and not bulk property setter/getter?

1 Like

This topic is about getting metadata about classes. Echo and I are saying that exposing the API dump would be a good way to do that.


In OP the primary thing was to be able to get the properties of an object.
As previously proposed a machine-readable API dump would solve this and more.

The whole :SetProperties() and :GetProperties() stuff isn’t really the main thing wanted here. It’s mostly some way (using methods in ScriptContext or another (or a new) service) to get info about a class(member), similar to the info that’s represented in the API Dump. We basically want a way to get the (up-to-date) API dump, preferably parsed into some table format, similar to (or just like) how the wiki does it:

1 Like

Ah, so you basically want a reflection system, I see. Yeah, I do agree that it might be useful for tool development, however, I do not yet see why it should be present at runtime.

1 Like

Some of my use cases addressed why it’d be useful to have online:


I don’t think this needs to be a runtime feature. An universal online properties window would be overkill, and a live scripting tutorial would need more annotation and guidance than the dump could provide.

Anyway, Anaminus’s dump parser would be a great starting point for the dump table format.

Output sample ``` { { tags = { notbrowsable = true; }; Name = "Instance"; type = "Class"; }; { Class = "Instance"; tags = {}; type = "Property"; ValueType = "bool"; Name = "Archivable"; }; { Class = "Instance"; tags = { readonly = true; }; type = "Property"; ValueType = "string"; Name = "ClassName"; }; { Class = "Instance"; tags = { readonly = true; RobloxPlaceSecurity = true; }; type = "Property"; ValueType = "int"; Name = "DataCost"; }; { Class = "Instance"; tags = {}; type = "Property"; ValueType = "string"; Name = "Name"; }; ```

We don’t see any compelling use cases for setting multiple properties with a single API call. Convenience seems like the only benefit. Also some properties must be set in a certain order, e.g. MaxHealth should be set before MaxHealth, so we wouldn’t know which order to apply the properties in. As a developer you can write your own libraries to do this easily.

It was already clarified on the thread that setting in a single API call wasn’t a very good request. The main thing developers wanted was the ability to query a list of an object’s properties.


It has been almost 3 years since this request and I still believe that this feature request is relevant. For my UI framework, I have to go through each individual property and set a default value. The code ends up looking somewhat like this:

Doing this for every component is very time consuming.

Using HTTPServices is a potential option but there are several drawbacks. For one, anyone who attempts to use it will have to enable HTTPServices. Secondly, I believe a built-in method would be more efficient than sending an HTTPRequest for every component.

If Roblox were able to address this, UI development would be significantly improved and those attempting to create custom solutions will be able to do so easily.


That code seems to have a lot of repetition – you probably want to make a list of properties instead and iterate over that, rather than writing up those whole lines all the time.

local properties = {"Text", "TextColor3", ...}


for _, property in ipairs(properties) do
   if Properties[property] then
      NewLabel.TextLabel[property] = Properties[property]

You can make a helper module for this that does this for any classes you use.

Not saying the need for this feature isn’t real, but it’s not as inconvenient if you structure your code more properly.


Check out this link for a solution: https://scriptinghelpers.org/questions/50784/how-to-get-list-of-object-properties

Using an external source to retrieve an API dump works but it’s really not ideal for long term maintainability.


I recently ran into a need to get the properties of an instance, and discovered that Roblox surprisingly hasn’t made this a feature yet.

The :GetProperties() feature would make it much easier for me to put together my project. Additionally, I’d love if the returned values also specified which category each property is under.

I decided to lua-ify the properties window, as well as make some minor improvements. Currently, I am creating a large ModuleScript filled with all the possible properties of each class, listed underneath the category they belong to.

Example of the property table I had to manually create for the "Part" class
["Part"] = {
	["Appearance"] = {
	["Data"] = {
	["Behavior"] = {
	["Part"] = {
	["Surface"] = {

If the returned table was similar to the one I created for each class, it would be extremely helpful to me personally. (and I’m sure it’d be helpful for others as well)

I could have used a HTTP request to a site that returns all the properties of an Instance, and that’s what I used for a little bit. However, I ran into the issue of it not telling me what category the property was under, therefore my property window was just a long list of every property with no organization.


6 years later and we still don’t have this as a feature.

The DevHub is already lacking information, I am trying to map all of the properties of a PluginToolbarButton as it’s DevHub page doesn’t include all of it.

Now I can’t even do that because of the lacking API.

Either give us:

  • Instance.Properties
  • Instance:GetProperties()

We have many valid use cases for this already stated all over the forum, what I don’t understand is why this hasn’t been implemented already? It’s just a table of properties!

Unity already has this built-in!

I have no idea what the property is called, I tried ToolTip, Tooltip, ToolTips, Tooltips, Text, Description


As a Roblox developer, it is too hard to develop decent plugins that handle multiple object properties. The current method involves getting the latest studio hash, getting a JSON file, and parsing it to a dictionary, all through a self-hosted proxy to bypass Roblox’s HttpService restrictions (public proxies don’t support the setup subdomain.)

“This isn’t worth adding because it only matters for plugins” isn’t a reasonable excuse because it implies that plugins are second-class citizens and their developers just need to deal with the hassle, and it’s also just wrong - my intent is to develop an in-game debugging tool to replace the Properties panel in Studio. Every 6 months I come up with a plugin idea that I ultimately have to scrap because I’m not able to spend all day on a single simple task like this.

If Roblox is able to address this issue, developers would be able to easily make all kinds of powerful plugins without resorting to hours of painstaking legwork.


Once again I’ve come across this same problem I’ve had many times in the past, usually when developing plugins, but here when developing for a production version of ingame code. This is useful for preserving state of an instance or group of instances which you can then revert to later.

For example if you have a ‘default’ configuration for anything in a game, currently you have to write a lot of code that reads, stores, compares and then writes to every property of an instance that could possibly be changed between it first existing and reverting those properties. I think in most cases, the easiest way of doing it and what most people are likely doing is making a clone of every instance and then destroying then reloading those stored clones when needed, but this is needlessly complex. I should be able to use GetProperties to get the current state of an instance and then SetProperties should automatically compare the properties of the instance with the table provided, and switch any that are different, that way you don’t need to Destroy and then re-insert new instances every single time you want to do this.

In this specific case I am only tracking one property, but with parameters for how granular you want to be with GetProperties and SetProperties this could still be done.

function GuiHandler.HideAll()
	local stateProperties = {}; -- save properties of screenguis to restore
	for id, ui in pairs (ScreenGuis) do
		stateProperties[id] = {Enabled = ui.Enabled}
		ui.Enabled = false

	return stateProperties

function GuiHandler.RestoreState(stateProperties)
	for id, ui in pairs (ScreenGuis) do
		ScreenGuis[id].Enabled = stateProperties[id].Enabled

I agree that this needs to be addressed. I can’t believe it’s still not a thing. I only require a :GetProperties() method for Instances, in all fairness. I can handle the rest from there. A way of retrieving the base class those properties are inherited from would also be extremely useful.

I’m currently looking to upgrade my Picular plugin, but this is something I’ll need access to, as I need to be able to determine which properties of the selected Instance(s) support Color3 values.

I really don’t want to have to explain to users that I need them to allow HTTP requests so I can find applicable properties; especially since I am not a member of the plugin marketplace, and therefore less reputable than other developers.


I cannot relate with this more.

We seriously need this functionality, Browser is using a tool I wrote to connect into clone’s API Dump.

However, this is not a long term solution, since the repository could be deleted/archived or Roblox remove the -API launcharg.

The fact this thread is six years old kinda brings up how much developers have wanted this feature.


  • Debugging Tools
  • Visual Programming Interfaces that need this information to better abstract code.
  • A FindFirstChild for properties.

Ran into this yesterday.

I wish Roblox Lua was more OOP. But failing that, I wish it were more like Javascript where I can reflect all the stuff I want and modify objects on the fly, adding new fields and methods to them.

Core Lua lets you do that, but Roblox Instances don’t. It’s weird?

This is fine:
a.fn = function() print("do stuff") end

This is not OK:
game.Terrain.ChangePalette = function() ... end

I think the reason is name collision in the datamodel tree because the dot operator is overloaded?

You can still do everything you want, obviously, since Lua is turing complete, so everyone here is just talking about QoL.