What a Figma plugin can and cannot know about its users
The Plugin API exposes a user id, a name, the editor and the mode, and nothing else. What that means for counting users, for privacy, and for the text in your Community listing.
, by Ilia
People ask two versions of this question. Plugin developers ask it because they want to count users. Designers ask it because they want to know what the plugin they just installed can see. The answer is the same short list, so here it is once.
What the Plugin API gives you
Inside code.ts, with the right manifest entries, a plugin can read:
| Property | Needs | What it is |
|---|---|---|
figma.currentUser.id | "permissions": ["currentuser"] | A stable id for the Figma account. Same across files and devices. |
figma.currentUser.name, photoUrl, color | same | Display name, avatar URL, the multiplayer cursor colour. |
figma.currentUser.sessionId | same | Changes every time the file is opened. Not an identity. |
figma.editorType | nothing | figma, figjam, dev or slides. |
figma.mode | nothing | How the plugin was launched: default, inspect, codegen and so on. |
figma.payments.status | "permissions": ["payments"] | Paid, unpaid or not supported, plus how long ago the user first ran the plugin. |
figma.clientStorage | nothing | A small key-value store on this machine, for this plugin. Yours to fill. |
That is the identity side of the API. The rest of it is the document: nodes, styles, selection, pages. A plugin sees everything in the file the user has open, which is the point of a plugin, and nothing about the user beyond the table above.
What it does not give you
- An email address, or any way to contact the user.
- The team, the organisation, the Figma plan, the seat type.
- The IP address. Neither half of a plugin can read it.
- Location. Figma does not expose it, and the plugin has no access to geolocation APIs.
- Other files, other tabs, the file history, the comments, who else is in the file (unless you look at
figma.activeUsers, which lists the people in the current file and needs the same permission ascurrentUser).
The UI iframe adds the usual browser facts (navigator.userAgent, screen size, language), but it runs in a null-origin frame with no cookies and no storage, so it cannot remember anything between opens on its own.
What that means for counting users
currentUser.id is the only durable identity a plugin has. Ask for the currentuser permission and you can count distinct users, tell new from returning, and compute retention. Skip it and you can count actions and sessions, but every one of them is anonymous. Figma shows the permission in the plugin's listing, so users know you asked.
Country has to come from a server. The request your plugin sends carries an IP like any other HTTP request; a server can look the IP up and keep the two-letter country code. That is what tode does: the controller asks the ingest service for the country once at init, the service answers with a code, and the IP is not written anywhere.
What tode stores, so you can write it in your listing
Each event has the action name and the metric value you pass, the Figma user id if your manifest requests it (otherwise an empty value), the editor type, the plugin mode, the Plugin API version, the country code and the timestamp. Sessions have a start, a length and the same context. Nothing else: no IP, no cookies, no user name or avatar, no file name, no layer, no document content. Events are deleted after the retention window of your plan.
A sentence for your Community description that covers it, if you use tode and want one:
This plugin collects anonymous usage statistics (which features are used, how long the plugin stays open, which Figma editor and country) through tode. It does not read file contents, layer names or your email address.
If you send events to a different service, write the same paragraph for that service. The honest version is short.
Two rules I would keep whatever tool you use
Never put a user's name, a file name or a layer name into an event name or a metric. Those end up in dashboards and exports and are impossible to take back. And never try to fingerprint users who did not grant the identity permission; an anonymous count of actions is still a useful number, and a half-working identity is worse than none.