API reference
Every programmable surface of paged in one place — the paged.* scripting API, the paged command line, the Viewer SDK, the editor-server REST API, and the plugin manifest — each generated from its own source of truth.
In short Paged exposes five programmable surfaces. Each reference below is generated from its own source of truth — the engine's scripting catalog, the CLI's own argument parser, the SDK package surface, the server's OpenAPI spec, and the plugin manifest schema — so none of them drift from the running code.
The Boa host API for inspecting and authoring the open document — every function and settable path, generated from the engine catalog.
The `paged` binary — author, render, export, read back and verify a document from a shell, over the same typed engine door the editor uses. Generated from the binary’s own parser.
The full @paged-media/idml-viewer surface — viewer lifecycle, camera, navigation, rendering, events, and every exported type.
The editor-server HTTP API — documents, assets, auth, and billing — generated from its OpenAPI spec.
The declarative contract a plugin bundle ships — capabilities, contributions, and manifest fields.
Which one do I want?
- Scripting (
paged.*)IntermediateII· explanationread and author the open document from inside the editor's script panel, the REPL, or headless viapaged-run. Start with the examples. - Command line (
paged)IntermediateII· referencethe same engine from a shell: author with a script, render, export, read back what a document holds, and verify it deterministically. The lane a build system wants. - Viewer SDKIntermediateII· explanationembed a WebGPU IDML viewer on a canvas: load a document, drive the camera, render to bytes, listen for events.
- REST APIProIII· referencethe editor-server HTTP surface for accounts, document storage, billing, and assets.
- Plugin manifestIntermediateII· explanationthe declarative contract a plugin bundle ships to contribute tools, panels, commands, and document behaviour.
What each one reaches
They all sound complete, and they are not equal. This table is generated from the capability × surface matrix, whose every cell comes from the gate that owns that surface — the engine's own CLI and scripting surface tests, the editor's probed capability table, each SDK's generated catalog. Nothing in it is written by hand, including the reasons a cell is not reachable.
| Surface | Authoring operationsof 150 | Message kindsof 69 |
|---|---|---|
| paged.* script functions (Boa bridge, in-worker) | 149 named · 1 generic | — |
| the `paged` command-line tool | 149 named · 1 generic | 38 of 69 · 31 not reachable |
| `paged session` / paged-run NDJSON | 149 named · 1 generic | 7 of 69 · 62 not reachable |
| @paged-media/client — the programmable SDK | 148 of 150 · 2 not reachable | 50 named · 19 generic |
| the editor application | 148 of 150 · 2 not reachable | 50 named · 19 generic |
| the plugin host contract (PagedClient) | 150 of 150 | 42 named · 27 generic |
| @paged-media/idml-viewer — the read-only viewer SDK | — | — |
named — a dedicated entry point spells the capability: a subcommand, a paged.* function, a typed method. generic — reachable through the surface’s general door, so nothing is blocked but the caller supplies the wire name. not reachable — and every one of those carries a written reason upstream, because a surface that quietly cannot do something is the failure this table exists to prevent. — — structurally not applicable: the viewer SDK has no write surface by design.
protocol 73 · 150 of 150 operations reachable from scripting
The two populations are the engine's own: an authoring operation is one
Mutation — insert text, resize a frame, create a swatch — and a message
kind is one request on the worker channel, which covers the reads, the
exports, the gestures and the container parts as well as the writes. A surface
that reaches every operation and half the message kinds can author anything and
ask fewer questions about it.
The editor itself is not a sixth entry here, and the reason is worth saying
rather than leaving as an omission: it has no API of its own. Everything it can
be driven to do it is driven to do through two of the surfaces above —
paged.* scripting for the document, and the plugin manifest for the interface
around it. A reference for "the editor" would be a third statement of those
two.
Versioning & compatibility
How the plugin API is versioned — apiVersion ranges and the 0.x caret rule, runtime capability detection with host.supports, the freeze policy for v1, and what plugin authors should pin.
REST API
The editor-server REST surface — authentication, files, account, billing, fonts, and image search — generated from the server's OpenAPI specification.