Same problem. I see the way, but this way will be dumb.
As the first query → getting styles using https://api.figma.com/v1/files/:file/styles.
As other queries → Getting properties from each style using https://www.figma.com/file/:key/:pageNames?node-id=:node_id
Same issue here, I was trying to use GET style, but there is no values either
https://www.figma.com/developers/api#get-style-endpoint
I was also wondering about this. It feels like the most important thing that you’re looking for in a style object would be its value. Is there a plan to include them going forward?
Just bumping this. Would really love to see this implemented - the API is really limited if we can’t get the style value.
I am bumping this once again. Has anyone heard anything from Figma regarding this discrepancy in the styles data object?
I think you can get the style values by querying for the nodes associated with it.
files/<key>/styles will give all the styles and in particular will give you the node_id of the node associated with that style.
You then do files/<key>/nodes?ids=<node_id-1>,<node_id-2>,<node_id-n> to get the information of all the nodes associated with the styles.
From the node you should be able to get the fills, effects, etc. which are the style values you’re looking for.
Bump. Even if the answer to this is “this is not he way we intended for the API to be used” that would be helpful, but apart from this just seems like a strange oversight.
+1
I will also be very happy when there is an API endpoint to get the styles and typography properties. E.G. with the ability to define a style format like “CSS”, “JSON”, “RESX” etc.
I our case it is the styles in a library that we need to extract.
The solution Nuna_Ferreira mentions requires the style to be use on a node to extract the style information and makes for unnecessary API calls and “jumping” in the JSON tree.
This should certainly be offered natively and such a request (single endpoint) to extract styles in json/etc format seems completely doable.
Ya… I just requested if this is available of a support contact I was given. I have zero hope tho that this is available directly, in ‘computed style format’, via the API.
I had to build a significant piece of code to do this using JSONPath-plus. Tho truth be told the ‘significant’ part of it is because I’m doing it within a Chrome extension, which has significant restrictions on what can be done where and how: requiring some of the logic done in the main extension javascript, some to be performed within an injected content javascript, and some of the logic done within a sandbox html file’s javascript.
… seems I can’t edit my replies to add add’l thoughts or fix typos …
So, by the previous comment I mean… I can use this JSONPath expression string to get to textract] a button’s text color from the large JSON object returned using the /nodes API call:
$..document..childrenn?(@.type==='TEXT')].fills
Be aware, this is for OUR design file. Yours will almost 100% need a different path to get to the figma spec definition you are interested in.
But that aside, the benefit of JSONPath expression strings is the ‘shortcut’ of ‘…’ that can be used to skip all the in-between levels. Since, as our design team structured their design file, this particular button’s text definition, searchable using the filter expression above, is technically at the following fully qualified path (which JSONPath-Plus will also give you):
"$)'nodes'] '3:1515']d'document']''children'][0]o'children']h1]d'fills']"
And finally, the JSON object value that is extracted from the JSON object the API for the node_id of the button in question that contains the button text’s color of ‘white’ is returned as:
e
{
"blendMode": "NORMAL",
"type": "SOLID",
"color": {
"r": 1,
"g": 1,
"b": 1,
"a": 1
}
}
]
]
…Ya, a single API call that returns #FFFFFF certainly would be better. lol. But this way, we have a job, right? 😉
(I was given rights to edit my posts. So I updated and fixed the formatting of my text above.)
@Steve_Mato Haha, no worries and goodness that’s quite a bit of work for this particular feature. Have yet to dive into the docs yet but if you don’t mind, let me pick your brain to get an idea of the scope of what I may have to build…
What I want to build is the ability to select frames/node, extract their styles, then send them to a database.
Seems like I need to try and organize the file so that I can read each node individually cleanly.
How manageable or unruly the JSON is that is returned from Figma using the most generic ‘/file’ end-point is directly proportional to the number UI design elements. And that determines how easily one can work with it within in a programmer’s editor, to find things like Node IDs and design property name/values under it.
You want to get the ‘node_id’ so that you can using the /nodes API call and return just one relatively small JSON object for just the one component. In our case, our primary design file returned a JSON file over 200 megs in size. That was basically impossible to open in even the most efficient programmer’s editor and search thru it to determine the node_id for a component I wished to process. Vs. the JSON object returned from the /nodes end-point is just a few down Kbytes in size.
Enter, a fantastic Figma plug-in someone -edit: jackiecorn Jackie Chui, on GitHub] wrote and put in the public domain, thereby available to everyone. If you need to get the node_id (and/or visually see all the first and second level name/values) of a component within Figma by clicking / picking it in the Figma UI, grab plug-in name ‘Node Inspector’. You can’t click an outer canvas or frame that contains many components and inspect that. But you can inspect a single Component and all the sub nodes under that. Which is perfect. (Make sure you drill-down the Figma component/instance/frame/whatever layering, as the right node_id you want may not be the top-level one.)
That served as a major leg-up in my processing of JSON returned from the Figma API. I don’t use the other data Node Inspector returns, other than eyeballing the design style name/value pairs. I just needed the node_id of a component. Then the rest of the work was in my logic running within a Chrome Extension to compare the Figma style values as the ‘source of truth’ to the rendered computed styles of html elements on our in-house built webapp pages.
Hope this helps. Let me know if you need more.
@Steve_Mato Steve, that was quite the insightful answer; thank you sir. Sadly, due to some deadlines and limited flexibility, going this route might not be feasible in my case.
Thinking about a decent workaround.
For now, I’m building a small application that can take my copy and pasted styles from figma inspect (I manually do this). Once the styles are pasted, I run my program that will take care of mapping/organizing and sending to the database. Not ideal, but could be sufficient.
Has anyone had any movement on this? We’re trying to extract all color usage (local/library styles, manual hex entry and swatches, and local/library variables) to audit usage across team files so we can help teams adopt tokens (styles presently; variables eval ongoing) as well as give us insight into DS deviation in an externally managed dashboard.
