Packaging, Importing & Updating

A plugin isn't locked to the platform you built it on — you can export it as a file, hand that file to someone else (or move it between your own environments), and they can import it in a few clicks. This article covers the package format, exactly what a package does and doesn't carry, how to import a plugin, and how to update one in place without losing its existing setup.

Exporting a plugin

From the Plugins area, you can export any plugin you've built into a single .json file. The export is available both from a plugin's card menu and from Quick Actions on the plugin's overview. The file is named after your plugin, so you'll get something like my-provider.json.

What a package contains

A package is a complete snapshot of how your plugin is built. It includes:

• Metadata — the plugin's name, type, description, and icon.
• Connections — each connection's settings, such as its base URL and authentication method.
• Flows — your visual flows, exactly as you wired them.
• Forms — any forms your plugin defines.
• Webhooks — your webhook definitions, including which flow each one triggers.
• Styling — the plugin's custom styling.
• Configuration schema — the field definitions for your configuration form (the keys, labels, types, and validation rules an operator fills in).

In short, everything needed to rebuild your plugin elsewhere travels in the package.

What a package never contains

Secret values are never included in a package. The configuration schema carries the definition of each secret field — that a field exists, what it's called, that it's a secret — but never the actual value that was entered for it. The same applies to credentials: a package describes how a connection authenticates, not the live keys behind it.

This is by design, so that sharing a plugin never leaks an operator's API keys, tokens, or passwords.

What this means in practice: after importing a plugin, the operator must re-enter every secret — API keys, tokens, passwords, and the like — before the plugin will work against the live service.

Importing a plugin

To bring a plugin in, go to the Plugins area and import a package file. Both a .json file and a .xzplugin archive are accepted as uploads:

1. Choose the .json or .xzplugin file to upload.
2. For a JSON import, you'll see a preview of what's inside before you commit — the plugin's name and type, and how many connections, flows, forms, and webhooks it contains.
3. If the import matches a plugin you already have, it automatically becomes an update rather than creating a second copy — an "Update available" notice appears and the action button reads Update Plugin. (See Updating a plugin in place below.)
4. Confirm the import.

An imported plugin always arrives as a Draft. That gives you a chance to review it, re-enter any secrets it needs, test it, and only then enable it — exactly the same lifecycle as a plugin you build from scratch. See Creating a Plugin for the Draft → build → Enable flow.

Updating a plugin in place

When you import a package that matches a plugin you already have, the import updates it in place rather than creating a duplicate. Updating in place:

• Brings in the new version's flows, forms, webhooks, styling, and configuration schema.
• Preserves the existing configuration and secrets the operator already entered, so the plugin keeps working without re-entering keys.

This is the clean way to roll out a new revision of a plugin you've shared: export the new version, and recipients update over their existing copy rather than starting over.

Related: Creating a Plugin · Configuration Settings · Connections and Authentication