How customers get, install and authorise your plugin

What the customer does

The platform administrator opens “Plugin store” (/dashboard/sys/plugin-store) and checks publisher, kind, version, price and permissions.
Free plugins are fetched directly; paid ones are bought first, then fetched. The plugin then appears in the tenant’s “Plugin marketplace”.
The tenant administrator reviews the permissions in “Plugin marketplace” (/dashboard/sys/plugin-market) and confirms; sensitive and new permissions are confirmed separately.
Enable and configure at the place for the kind (table below), then use the target role on the real page to check saving, reloading and one real call.

Kind	Where to enable in the control plane
theme	Themes, /dashboard/sys/themes
rule_pack	Rule packs, /dashboard/site/rule-packs
provider	Third-party providers, /dashboard/sys/plugin-providers (the installation contract must pass first)
ui_page, external_service	The target tenant’s plugin marketplace list

Identity and permissions

Action	Needs
Browse and buy	Platform administrator, marketplace.browse / marketplace.purchase
View tenant installations	A session in the target tenant with plugin_installations.read
Confirm, upgrade, disable, uninstall	plugin_installations.manage; the endpoints need If-Match and Idempotency-Key

Platform and tenant identities have different scopes; a username alone does not tell you which one is active. A developer can never approve installation permissions for the customer.

Installation states

State	Meaning
pending_confirmation	Fetched, waiting for the tenant administrator to confirm permissions
authorized, installing	Confirmed, installing
enabled	Enabled and active
disabled	Disabled: pages removed, calls refused, no new events
upgrade_failed_lkg_preserved	Upgrade failed; the last known good version is kept
uninstalled	Uninstalled; authorisation revoked

A plugin in the list still needs to be confirmed, enabled and configured.