Plugin SDK
How third parties extend paged — the plugin contract, the manifest, the capability model, and the lifecycle. The capability and contribution vocabularies are generated from the manifest schema.
In short a paged plugin is a bundle that declares a manifest — an identity, the capabilities it needs (document access, rendering surfaces, network, storage, …), and the contributions it adds (tools, panels, commands, object types). The host grants only what the manifest declares; capabilities are a closed, enforced vocabulary. The five first-party content plugins (draw, web, image, sheets, data) are built on this same contract.
The packages
@paged-media/plugin-api— the type-only contract: the editor-host handles and the manifest types. No runtime code; a plugin compiles against it.plugin-sdk— runtime helpers: theBundleHostadapter, the loader, the gesture kit.plugin-cli— a zero-dependency manifest validator (paged-plugin validate).
The manifest
Every bundle ships a manifest.json. Its fields, capability vocabulary, and
contribution kinds are a single source of truth (a JSON Schema, per ADR-019);
the pages here are generated from it.
| Field | Required | Shape | Notes |
|---|---|---|---|
| id | required | string | Reverse-DNS plugin identity; namespace prefix for all contribution ids. |
| name | required | string | |
| version | required | string | |
| apiVersion | required | string | |
| publisher | optional | string |
Where to go next
- Capabilitiesthe closed set a manifest may request, and what each grants.
- Contributionsthe surfaces a plugin can add to the editor.
- Build a pluginstart from the template and ship.
Sandbox & budgets
The execution model for paged.* scripts — a pure ECMAScript sandbox with no I/O, plus the runtime budgets that keep scripts safe — generated from the engine catalog.
Capabilities
The closed set of capabilities a plugin manifest may request — document access, rendering surfaces, network, storage, workers, and more — generated from the manifest schema.