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

Say you are trying to hit an API endpoint from inside your plugin, and you’ve already tested the exact fetch call in your browser console — it works, returns the data you expect, no issues. You paste that same code into your plugin, run it, and instead of your data you get a network access error staring back at you. Same URL, same request, same everything. The difference isn’t in your code at all — it’s the sandbox your plugin is running inside, and it’s blocking that call on purpose.

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

Every plugin runs inside a sandboxed environment that restricts network access by default, and that restriction is there as a deliberate security boundary rather than an oversight. Plugins are third-party code executing with access to whatever file the user has open, so if network requests went unrestricted, any plugin could quietly ship file contents (or anything else) off to an external server with no visibility into it for the person running it.

The Fix: Declaring networkAccess in manifest.json

Requests are only allowed to domains you’ve explicitly listed in the plugin manifest, under a networkAccess field built for this purpose.

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

Worth checking directly: when a fetch call fails, line up the exact domain being requested against what’s listed in your manifest — protocol included. An entry of https://api.example.com covers a request to https://api.example.com/v2/data just fine, but swap in a different subdomain or drop down to http instead of https, and the request gets blocked regardless of how close it looks to what’s allowed.

Avoid Reaching for a Wildcard

You can technically list "*" and open the door to every domain, but there’s almost no scenario where that’s the right call. Setting aside the obvious security tradeoff of allowing requests anywhere, plugins going through community publishing review get looked at more closely when a wildcard shows up, compared to a manifest that spells out the specific domains the plugin genuinely needs.

Local Development Domains: devAllowedDomains

For domains you only need while building locally — a localhost server, say — there’s a separate field: devAllowedDomains. It keeps those entries out of the domain list your published plugin actually ships with.

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

Worth using when: your local setup talks to a different URL than production does, and you’d rather not have a localhost entry sitting in your published manifest doing nothing once the plugin is live.

The Follow-Up Bug This Often Causes Later

Here’s a pattern to keep an eye out for: a plugin runs fine for months, then a new feature brings in a fetch call to a domain you haven’t used before, and suddenly that one call fails while everything else keeps humming along. Nine times out of ten, the new domain just never made it into allowedDomains — the rest of the manifest is untouched and correct. Since every other call is still succeeding, it’s tempting to rule out the manifest and start debugging somewhere else 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.