The Figma Plugin API gives you access to large parts of Figma documents. It already contains more than a hundred methods and properties, but it is still very new and there is still more to add.
Some APIs are harder to create than others. There are technical difficulties and security concerns that are not always obvious. Ironing them out will take time. Our #1 priority is to keep Figma stable, even when plugins are in use, so that it stays the design tool you want to use both now and in the future.
This page is to let you know we're keeping track of requests, and to answer the most common questions of the form "do you have this API?" and "when will you have this API?"
You can help us by sending detailed descriptions of plugins you want to build and how these plugins would use these APIs. This may allow us to design partial solutions that satisfy the needs of most plugin developers.
✅ Reading layers and layer properties in the local file
Plugins expose, first and foremost, the content of a file. That's anything that's in the layers panel or properties panel (there are over a hundred properties!). Plugins can change a layer's color, position, hierarchy, text, etc.
(There may be a few properties that we missed, but these are generally straightforward for us to add on request.)
Components and styles are available if they exist or are used in the file the plugin is running in.
✅ Create a modal with custom UI
A plugin can open a modal (
✅ Access browser APIs
Since (part of) the plugin runs in an
<iframe>, you can access browser APIs. This includes making network requests, opening files, using
<canvas>, using WebGL, using WebAssembly, using audio APIs, etc.
If there is demand, we are likely to add these in the timespan of a few weeks to a few months.
🕐 Overrides API
We know a lot of you want to know if a value is on an instance because it's inherited or overridden. This requires some work to design as it interacts with our complex components system.
⚠️ Feedback needed! We would like more data on how people would use an overrides API before proceeding.
These are more things we didn't have the time to do for v1.0.0, but aren't out of the question. For example:
- detach instance
- outline stroke
- selection inside text (and better text APIs)
Note: not a roadmap
These are projects we'd like to do because many people ask for them, but have a lot to consider before they can be done. They could turn to be easy for us to add, but they could also turn out to be big projects. We don't have a timeline on these yet.
🗄️ Access to file, user, team info, comments
The current plugin model is simple: plugins only have access to the content of the document. If given access to things like to user and file IDs, plugins could track your activity or access your file after you closed it. This is probably not what you want, even for files that are world-editable. These are issues that can be solved, but that require design (e.g. how should we ask the user for permission?)
🗄️ Full access to team library
Similarly, access to team library content is outside the current plugin model. Third-party plugins being able to crawl an entire organization's assets is a security concern. This is also a solvable problem that requires careful design.
🗄️ Trigger plugin code on events
Certain types of plugins would like to run code if an event happens in the document (e.g. selection changes, frame is resized). Some challenges there include:
- Degraded performance. These events can happen multiple times a second. Having many (potentially inefficient) listeners would make Figma slower for you.
- Internal stability. Code that runs at unexpected times could break internal invariants and cause crashes. We need to audit our code to prevent that from happening.
- External stability. Many different actions can cause events to fire. New features could cause events to fire under different circumstances. This means that allowing plugins to fire on events could lead to many more ways for a plugin to break when we update Figma.
These issues are solvable but require careful design.
🗄️ Long running/background plugins
A harder version of the above. All of the same concerns exist, and it may not even be clear that a plugin is running at all (or causing the slowdown). Browsers support WebWorkers, but these wouldn't have access to the document (not easily, at least).
🗄️ Multiple simultaneous plugins
Security is a concern here, as we wouldn't want one plugin to be able to read another plugin's sensitive information (e.g. login credentials). There are also increased stability risks as plugins can't reasonably predict all the possible ways plugins might interfere with each other.
🗄️ Plugins in the properties panel/toolbar/etc
This potentially has all the challenges of "trigger plugin code on events", "long running plugins", and "simultaneous plugins."
There are also design problems to solve in ensuring that plugins match the Figma UI while also being identifiable as a plugin.
🗄️ Keyboard shortcuts for plugins
This is another common request. We're likely to do this, but there are many details that makes this harder to do right than it sounds. For example, plugins can have overlapping shortcuts, and it's important to prevent shortcut hijacking upon plugin installation.
🗄 Plugins in the file browser
This is an entirely different set of APIs and runtime environment. This may take the form of a REST API rather than a plugin API.
🗄 Access to version history/multiple files
This is also more likely to take the form of a REST API than a plugin API. In both cases, loading another file in the same browser tab is not something the app is designed to support. And even if it did, it could easily make the tab run out of memory given how large files our users create sometimes.
🗄 Helper functions APIs
There's a lot of functionality that we could but don't provide in the Figma Plugin API because implementing them is possible using what is already provided.
For example, a helper function
createComponentFromFrame can be implemented by creating a component and then moving the frame's layers into it.
It's important that we keep the core API as small as possible while giving you access to the correct data. This minimizes the risk of changes to the API breaking your plugins. As such, we won't include functions that you could write with the existing API.
If there's sufficient demand, however, we might create a separate library of helper functions, separate from the core Figma Plugin API.
🗄 Figma UI components for plugins
Being able to import components (e.g. in React) of Figma buttons, color picker, etc would speed up plugin development. This would also be a separate library, not part of the core Figma Plugin API.
🗄 Plugin analytics and error reporting
To better support plugin developers, we would love to provide analytics regarding plugin usage and crashes that users run into. It's not fundamentally hard, but also not a small project. In the meantime, you will need to use your own analytics/crash reporting service.
We're probably not going to do these.
❌ Desktop-specific APIs
The two main issues here are:
- Compatibility. Not all users of Figma use the desktop app, and we'd like plugins to be cross-platform just like Figma itself.
- Security. A native application has access to your filesystem and everything else on your computer. We don't want any third party-code to have such access. A desktop API would need to be designed very carefully.
Note that browsers already come with APIs such as reading files and saving files. Browser engineers have already put a lot of hard work into creating secure APIs, and we are content to follow their lead.
❌ Loading an external font
We're unlikely to provide a way to load a font from a URL and use it inside Figma. Such a font would either need to be stored on the server, or locally on your computer. We can't store arbitrary fonts on servers due to font licensing issues, and storing locally is a desktop-specific functionality.
(This does not apply to using fonts in the plugin's UI, which can be done like any regular website).