Skip to main content

Plugin API request: Expose a stable, non-duplicable file identifier to plugins

  • April 21, 2026
  • 1 reply
  • 14 views
GiroXIII

Many developers have been asking for access to the file key from the Plugin API for years. The consistent answer is that file keys can't be exposed to public plugins for security reasons, and the only workaround is asking the user to paste the file link — which is frictional, unreliable, and doesn't survive file duplication.

The core problem

Plugins frequently need to associate per-file state (settings, subscriptions, licenses, local caches, external resource mappings) with the specific file they're running in. The current options all break down:

  • figma.root.setPluginData — stored inside the file's content, so it's copied verbatim when the user duplicates the file. Any custom file ID we generate and store is cloned along with it.
  • figma.clientStorage — scoped to the user's device, so it doesn't persist across collaborators, browsers, or machines. Useless for file-scoped state.
  • User-pasted URL — adds friction, has to be re-requested after duplication (but we can't detect the duplication, so we don't know when to re-prompt), and can be forged.

The result: there is no reliable way, from within a plugin, to tell whether the current file is the one the plugin was originally registered in. This is a blocker for anything involving per-file billing, licensing, or integrity-sensitive state.

The request

If exposing the file key directly is off the table for security reasons, please expose any stable, read-only, file-scoped identifier that:

  1. Is unique per file
  2. Is stable across sessions and collaborators (same file → same ID for everyone editing it)
  3. Is different when the file is duplicated (new file → new ID)
  4. Cannot be written to, set, or forged by the plugin

It doesn't have to be the file key — an opaque hash or derived identifier is fine. The goal is purely file identification, not access to any Figma-level capabilities tied to the file key.

Use cases this unblocks

  • Per-file subscriptions / licensing (preventing a paid subscription from being copied to N files via duplication)
  • Reliable per-file external resource mapping (e.g., linking the file to an external project in another tool)
  • Accurate telemetry and analytics
  • Crash/bug reports that can reliably point to a specific file
  • Any integration where "same file, different session" and "different file, duplicated from same source" need to be distinguishable

    1 reply

    Liviu
    • Liviu
    • New Member
    • April 24, 2026

    +1 to this request — this would solve a real limitation for public plugin developers.

    I’m working on a public plugin integration with POEditor, and I’ve run into the exact same issue: there is currently no reliable, supported way to identify the active Figma file from a Community plugin.

    For integrations like localization, the plugin often needs to associate external data with the specific file it came from. In my case, text node IDs alone are not enough because node IDs are only meaningful within the context of a file. The same node ID can exist in another file, so without a stable file-level identifier, mappings become fragile.

    I also agree with the core distinction in this request:

    • We do not need access to sensitive file capabilities.

    • We do need a stable, read-only, file-scoped identifier.

    An opaque identifier would be completely sufficient if it has these properties:

    • Unique per file

    • Stable across sessions and collaborators

    • Changes when the file is duplicated

    • Read-only / not forgeable by plugins

    That would unlock a lot of legitimate use cases for public plugins:

    • Localization sync (Figma file ↔ translation project)

    • External asset/project mapping

    • File-scoped settings

    • Reliable analytics/debugging

    • Safer automation workflows

    Right now the available workarounds (manual URL paste, pluginData, clientStorage) all have major tradeoffs and don’t fully solve the duplication problem.

    Even if exposing fileKey itself isn’t possible, a separate opaque fileId or similar API would be incredibly valuable for the plugin ecosystem.

    Strong support for this feature.

      Terms & ConditionsCookie settingsAccessibility statement