# How to collect feedback for a Figma plugin

> A Figma plugin sends feedback from its UI iframe with fetch, after the Escuta Produto domain is listed under networkAccess in the manifest. Add a link to the hosted form for longer notes, and store the plugin version and editor type as metadata so reports match the release that produced them.

Source: https://escutaproduto.com/resources/collect-feedback-figma-plugin
Last updated: 2026-10-11

## Why the plugin UI sends the report

A Figma plugin has two parts. The code file runs in a sandbox with access to the document, and the UI file runs in an iframe that can show HTML and make network requests. Feedback belongs in the UI, because only the UI can reach an outside server. The code side can hand the UI details such as the editor type, but it should not send anything itself.

The widget script cannot run inside the plugin UI in a useful way, because the panel is small and the widget's floating button and form would compete with the plugin's own controls. A short form in the plugin UI, plus a link to the hosted page for longer messages, works better. The [REST API reference](/docs/api) lists the fields, and a successful send returns `201` with the item `id`.

## Allow the Escuta Produto domain in the manifest

Figma blocks network requests to domains that a plugin has not declared. Add the Escuta Produto origin to `networkAccess` in the plugin manifest:

```json
{
  "name": "Your Plugin",
  "id": "1234567890",
  "api": "1.0.0",
  "main": "code.js",
  "ui": "ui.html",
  "editorType": ["figma", "figjam"],
  "networkAccess": {
    "allowedDomains": ["https://escutaproduto.com"]
  }
}
```

Figma's manifest rules change with the plugin API version, and the validator may ask for more fields. Check the current plugin documentation when you publish, and keep `allowedDomains` limited to the domains you really call. A plugin that lists only one domain is easier to review.

## Add a feedback panel to the plugin UI

Keep the panel small. Four type buttons, a message box and a send button are enough, plus one link to the hosted form. Designers open plugins while they work, so a long form in a narrow panel will go unused.

1. Add the four types as buttons: bug, idea, praise and other.
2. Add a message box with a minimum length of two characters.
3. Add a send button that is disabled while a request is in flight.
4. Add a link that opens the hosted form for longer messages or attachments written in the browser.

Test the link in both the desktop app and the browser version of Figma. If it does not open in one of them, show the address as plain text so the designer can copy it.

## Send from the UI with fetch

The UI receives the plugin version from your build step and the editor type from the code file. The code file sends the editor type once when the plugin starts:

```js
// code.js, runs in the plugin sandbox
figma.ui.postMessage({ type: "editor", editorType: figma.editorType });
```

The UI keeps both values and sends the report with `fetch`. The build step writes the version into the UI file, so the number in the report always matches the released plugin:

```html
<script>
  const PLUGIN_VERSION = "2.4.1";
  let editorType = "unknown";

  window.onmessage = (event) => {
    const message = event.data.pluginMessage;
    if (message && message.type === "editor") editorType = message.editorType;
  };

  async function sendFeedback(message, kind) {
    const response = await fetch("https://escutaproduto.com/api/v1/feedback", {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        key: "pk_your_product_key",
        kind: kind,
        message: message,
        metadata: { pluginVersion: PLUGIN_VERSION, editorType: editorType },
      }),
    });
    return response.status === 201;
  }
</script>
```

The function returns `true` only when the API answers `201`. Show a short confirmation in the panel on success and keep the typed text on failure, so the designer can try again without retyping.

If your product uses allowed origins, check the REST API reference before you rely on the list. Requests from a plugin iframe do not carry the same origin as a normal web page, so test the send from a real plugin session and confirm that the item appears in the inbox.

## What metadata makes a plugin report useful?

Plugin reports are most useful when they name the release and the editor. The table below shows the keys worth sending:

| Key | Source | Why it helps |
| --- | --- | --- |
| pluginVersion | build step | Connects a report to the release that produced it |
| editorType | figma.editorType | Separates design files from FigJam boards |
| kind | the button the user chose | Keeps bugs apart from requests |

Do not send file names, layer names, file keys or any part of the design. Designs are confidential, and a feedback report should describe the plugin's behavior, not the client's work. If a bug depends on a specific layer type, the designer can describe it in the message.

Keep metadata small. Three short values are far below the 4 KB limit, and short values are easier to read in the inbox and in a CSV export.

## How do you handle a plugin that is blocked or slow?

Designers sometimes work offline or on a network that blocks outside domains. The send should fail gently. Show the hosted form link as a fallback, keep the text in the box, and log a short message in your own console for debugging. Do not block the plugin's main features while the request runs.

Rate limiting is per IP address and product. A design team in one office shares an address, so 10 requests per minute can be reached if many designers send feedback together. A simple cooldown in the panel, such as one report every 30 seconds, keeps a single team under the limit.

## Connecting the plugin to Escuta Produto

Create a product for the plugin and copy its public key into the UI build. Add the Escuta Produto domain to the manifest, then install the plugin from a development build. Send one report, and check the inbox for the plugin version and the editor type. Connect the Slack or Discord webhook next, so new reports reach the team.

The notification guide in the [docs](/docs/notifications) covers the webhook. For the team's routine, the [triage guide](/resources/how-to-triage-customer-feedback) describes how to sort reports into statuses. If your plugin is part of a larger product, the [SaaS article](/resources/collect-feedback-saas) shows how to place entry points inside an app, and the [mobile app article](/resources/collect-feedback-mobile-app) covers the same REST API pattern for another kind of client.

## Frequently asked questions

### Can a Figma plugin send feedback to an outside server?

Yes, from the plugin UI, as long as the server's domain is listed under networkAccess in the manifest. The code file cannot make network requests, so send the report from the UI iframe.

### What should a Figma plugin report include?

Include the plugin version from your build, the editor type such as design or FigJam, and the kind the user picked. Do not include file names, layer names or any part of the design.

### Why does the feedback request fail in the plugin?

A frequent cause is a missing domain in the manifest. Check that the Escuta Produto domain is listed, rebuild the plugin and test it again. If the product sets allowed origins, check that setting too.