Plugins

Packaging, Importing & Updating

A plugin isn't locked to where you built it. Export it to a file, hand that file to someone else, and they can import it in a few clicks — this article covers the package format, what travels in it, and how to update a plugin in place.

Updated · 2026-09-03

A plugin isn't tied to the installation 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 import it in a few clicks. This article covers what a package holds, what it deliberately leaves out, how to import one, and how to update a plugin in place without losing its existing setup.

How to reach it

Open Settings → Integrations → Plugins. Import sits in the header beside New Plugin. Exporting is on each plugin card's menu as Export JSON, and inside the plugin's Overview tab under Quick Actions as Export Plugin. The same Quick Actions panel offers Duplicate Plugin, which makes a fresh copy on this installation without a file round trip.

Exporting a plugin

Exporting downloads a single .json file named after the plugin, so a plugin called My Provider gives you my-provider.json. That one file is a complete description of how the plugin is built.

What a package contains

Plugin details — name, slug, type, description, icon, service type, the capability declarations, and the package version.
Connections — each connection's name, slug, base URL, authentication type and its non-secret settings, default headers, insecure-SSL setting, timeout and retry count.
Flows — the canvas exactly as you wired it, plus each flow's name, slug, type, operation, description, action button name, label and icon, schedule settings, input and output schemas, timeout, retry settings and whether it is enabled.
Webhooks — each endpoint's name, slug, HTTP method, verification type and the structural parts of its verification settings, the flow it triggers, and whether it is enabled.
Forms — any forms the plugin defines, with their fields, layout and validation.
Styling — the plugin's custom styling.
Config schema — the field definitions for your configuration form: keys, labels, types, groups, conditional visibility and validation rules.

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

What a package never contains

No secret value is ever included. The config schema carries the definition of each secret field — that it exists, what it is called, that it is a secret — but never the value entered for it. The same is true of connections: the package describes how a connection authenticates, not the key behind it. Webhook signing secrets and expected tokens are stripped too; only the structural settings survive, such as the header name and the algorithm, along with the name of the configuration field a secret is read from.

What this means in practice: after importing a plugin, re-enter every secret — API keys, tokens, passwords, webhook signing secrets — before the plugin will work against the live service. Until then, webhook verification refuses deliveries rather than accepting them unchecked.

Importing a plugin

Press Import and choose or drag in the file. Both a .json file and a .xzplugin archive are accepted.
For a .json file you get a preview before committing: the plugin's name, type and description, and counts of the connections, flows, forms and webhooks it carries. An archive shows its file details only.
If the package matches a plugin you already have, an Update available notice appears naming the installed plugin and its status, and the button changes to Update Plugin.
Confirm. The imported plugin opens in the editor.

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

A package is rejected if it is missing the plugin's name or type, if its type isn't one the platform recognises, or if a flow or form inside it is missing its own name or type.

Updating a plugin in place

When you import a package whose slug matches a plugin you already have, the import updates that plugin instead of creating a duplicate. Updating in place:

Keeps the plugin's slug, its status and its configuration values — including secrets. An enabled plugin stays enabled and keeps working without re-entering keys.
Brings in the new version's connections, flows, forms, webhooks, styling and config schema, matching them by slug so an existing connection keeps the credentials attached to it.
Removes connections, flows, forms and webhooks whose slug is no longer in the package. If the new version dropped or renamed something, the old one goes with it.

Warning: because matching is by slug, renaming a slug between versions reads as “the old one was deleted and a new one added”. A renamed connection loses the credentials that were attached to the old slug. Keep slugs stable across releases.

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 again. An item that came from your panel's own catalogue is updated differently — see Plugin Catalogue.

Moving a plugin between your own installations

Export the plugin from the source installation.
Import the file on the destination. It arrives as a Draft.
Open its Connections tab and re-enter the credentials for each connection, then use the test button on each one.
Open its Config tab and fill in every secret field.
If it has webhooks, open the Webhooks tab, re-enter the signing secret or token, and paste the endpoint URL shown there into the provider's dashboard.
Run each flow once from the builder's Test panel, then Enable the plugin.

All topics Suggest an edit →