Developing a plugin

An Altretta plugin is code written against Altretta's plugin API, packaged for the official catalog, and — like every plugin — signed, sandboxed, and permission-scoped. This page is a conceptual orientation for developers deciding whether to build one; it points you to the official sources rather than restating an API here.

What building a plugin looks like

At a high level, a plugin is a JavaScript package that:

• Targets Altretta's plugin API to add commands, workflows, and — optionally — panels to the app.
• Declares the permissions it needs. The sandbox denies by default, so a plugin explicitly requests any capability it requires — for instance, permission to read note contents. Users see and approve those scopes before the plugin runs.
• Runs in the sandbox. Your code executes in an isolated JavaScript runtime with no unfettered filesystem, network, or system access. Design around the API surface Altretta exposes rather than reaching for the host system directly.
• Is packaged and signed for distribution, so Altretta can verify authenticity at install time.

Because these constraints are the product's security guarantees, they shape design from the start: request the minimum permissions, and build the plugin's features on top of the documented API and render protocol.

The permission-first mindset

The single biggest difference from developing for an app with full-access plugins is that you can't assume ambient access to anything. Decide early exactly which capabilities your plugin genuinely needs, request only those, and expect users to see that list. A tightly-scoped plugin is easier for users to trust and to approve.

Developer Mode

You don't have to publish to the Hub to run your own code. Developer Mode lets you build and test a plugin locally, against the same sandbox and permission model real users will see:

• Load an unsigned plugin folder. Point Altretta at a working directory and it loads your plugin without a Hub signature — so you can iterate before anything is packaged. Unsigned plugins are clearly marked as development builds.
• Hot-reload on change. As you edit your source, Altretta reloads the plugin so you see changes without a full restart.
• Manage a local author signing key. Generate and keep a personal signing key on your machine, used to sign your own builds during development.
• Package and sign a folder into a .akplugin. When you're ready, bundle the plugin directory into a single signed .akplugin artifact — the same signed, verifiable format the Hub distributes — so it can be installed and its authenticity checked like any other plugin.

Publishing to the catalog

Altretta plugins are distributed through the official, first-party Hub. The first-party catalog lives in a public repository, which is the reference for how plugins are structured, packaged, and submitted. Because the Hub is curated and signed, distribution goes through that path rather than arbitrary URLs.

Related