Admin UI Plugin Management
Open the Admin Console’s plugin page at /admin/plugins. The list combines discoverable built-ins with approved dynamic Worker entries. What you can change depends on your administrative scope and the selected tenant.
List and details
Section titled “List and details”Filter by category or enabled/disabled status, open a plugin’s details, and inspect its metadata and configuration. A registry entry is not proof that the provider is configured or that an installation is ready.
The current UI supports configuration editing, enable/disable controls, health-status retrieval, and test email for eligible notifiers. Dynamic plugins can also expose resource selections, provisioning state, and uninstall controls. Do not expect an arbitrary npm-package installer or automatic npm update discovery.
Configure and enable
Section titled “Configure and enable”- Confirm the tenant/platform scope.
- Enter the required configuration and credentials.
- For a dynamic plugin with resources, choose supported managed/existing resources.
- Save and enable, then inspect any provisioning state before relying on execution.
- For email, use the test-email action and verify delivery to the intended recipient.
Global provider changes can trigger reprojection jobs. Platform administrators can inspect that progress; tenant administrators do not get platform-wide rollout visibility.
What “health” means
Section titled “What “health” means”The health endpoint currently returns the last stored status from KV, or unknown if none exists. Clicking the health action retrieves that status; it does not necessarily make a fresh request to the provider. Automatic periodic checks, checks on every configuration change, and dependency impact previews are not guaranteed by this screen.
A test email is a separate operation that attempts delivery. It is more direct evidence of the configured email path, though acceptance by a provider is not proof of inbox placement.
API mapping
Section titled “API mapping”| Operation | Tenant API |
|---|---|
| List / details | GET /api/admin/plugins, GET /api/admin/plugins/:id |
| Read / update config | GET / PUT /api/admin/plugins/:id/config |
| Reset config | DELETE /api/admin/plugins/:id/config |
| Enable / disable | PUT /api/admin/plugins/:id/enable, PUT /api/admin/plugins/:id/disable |
| Test email | POST /api/admin/plugins/:id/test-email |
| Uninstall dynamic plugin | POST /api/admin/plugins/:id/uninstall |
| Stored health / schema | GET /api/admin/plugins/:id/health, GET /api/admin/plugins/:id/schema |
Platform routes use /api/admin/platform/plugins and require system-admin authority. They include provider-projection status and dynamic rollout operations. Do not assume every tenant operation exists under the platform prefix.
Troubleshooting
Section titled “Troubleshooting”- Missing plugin: verify manifest publication or bundled registration, not just the package installation.
- Secret save rejected: verify the plugin encryption key and required credential slots.
- Enabled but unavailable: inspect provisioning, active version, policy, required resources, and provider projection status.
- Unknown health: no stored observation is available; use the relevant functional check.
- Disable versus uninstall: disable stops use; uninstall has its own lifecycle and resource handling.
See Configuration and Deployment for backend-specific details.