Why fetch() Fails in Your Figma Plugin (And How to Fix the networkAccess Permission)

A developer copied a working fetch call directly from a browser console test, dropped it into their plugin’s code, and watched it fail immediately with a network access error, despite the exact same URL and request working perfectly everywhere else they had tried it. Nothing was wrong with the fetch call itself. The plugin sandbox was deliberately blocking it.

Why Figma Plugins Can’t Just Call fetch() Freely

Plugins run inside a sandboxed environment with deliberately restricted network access by default. This exists specifically as a security boundary: plugins execute arbitrary third-party code with access to whatever design file they are running inside, and unrestricted network access would mean any plugin could silently send file contents or other data to an external server without the user having any way to know this was happening.

The Fix: Declaring networkAccess in manifest.json

Network requests are permitted only to domains explicitly listed in the plugin’s manifest file, under a dedicated networkAccess field.

{
  "networkAccess": {
    "allowedDomains": ["https://api.example.com"]
  }
}

Worth checking directly: if your fetch call is failing, confirm the exact domain your request targets matches what is listed here precisely, including the protocol. A request to https://api.example.com/v2/data is permitted by an entry of https://api.example.com, but a request to a different subdomain or a different protocol will still be blocked even if it looks closely related.

Avoid Reaching for a Wildcard

It is technically possible to list "*" to permit all domains, but this is worth avoiding in almost every real case. Beyond the security downside of permitting requests to literally anywhere, plugins submitted for community publishing get reviewed, and an unrestricted wildcard tends to draw extra scrutiny during that review compared to a manifest that explicitly lists the specific domains the plugin genuinely needs.

Local Development Domains: devAllowedDomains

A separate field, devAllowedDomains, exists specifically for domains you only need while developing locally — a localhost development server, for example — that should not necessarily be part of your published plugin’s permitted domain list.

{
  "networkAccess": {
    "allowedDomains": ["https://api.example.com"],
    "devAllowedDomains": ["http://localhost:3000"]
  }
}

Worth using when: your local development setup points at a different URL than your production API, and you do not want your published manifest cluttered with a localhost entry that has no purpose once the plugin is actually published.

The Follow-Up Bug This Often Causes Later

A specific pattern worth watching for: a plugin works correctly for months, then a new feature adds a fetch call to a different domain, and that one new call fails while everything else keeps working fine. This is almost always because the new domain was never added to allowedDomains, even though the rest of the manifest is correct. Since the existing calls succeed, it is easy to assume the manifest is fine and look elsewhere first.

A Quick Reference

Is your fetch call failing inside the plugin sandbox specifically, or somewhere else in your code? Share the exact error message and I can help you pin down whether this is a manifest issue or something else.