Extensibility Internals
The plugin SDK message protocol, the iframe sandbox, manifests, lifecycle, and how integrations surface data.
Overview
Pomavo is extended without ever modifying the core. Plugins run as isolated web apps embedded in the UI, first-party integrations like GitHub surface external data through search indexes, and the MCP server exposes Pomavo to AI agents. This page explains the mechanics behind each.
The Plugin Sandbox
A plugin is a web application you host. Pomavo embeds it in a sandboxed iframe granted only the capabilities it needs, scripting, same-origin for its own resources, and popups. The plugin cannot reach into the host page's DOM, cookies, or storage; the only channel between plugin and host is structured messages.
The host validates the origin of every incoming message against the plugin's registered origin, so a plugin frame can only ever speak for itself.
The SDK Message Protocol
Communication is a small, typed postMessage protocol, wrapped by an official SDK so plugin authors never handle raw messages. The handshake is a request/response dance:
Plugin signals ready
On load, the plugin announces it has initialized.
Plugin requests context
The plugin asks the host for its context.
Host delivers context
The host responds with the plugin's context: a scoped token, the plugin's saved settings, and the relevant ticket reference when the plugin is rendered on a ticket.
Host pushes updates
The host notifies the plugin of relevant changes, such as when the user switches theme, so the plugin can stay visually consistent.
Plugin requests resize
The plugin tells the host its desired height so the iframe fits its content seamlessly.
This means a plugin receives exactly the context it needs and a token scoped to act on the user's behalf, never broad access to the host.
Manifests and Lifecycle
A plugin is registered with a manifest describing its identity, the URL to embed, where it should appear in the UI, and the settings it exposes. Administrators install and configure plugins; the manifest tells Pomavo where to surface the plugin and what settings UI to render. Settings are stored by Pomavo and delivered back to the plugin as part of its context.
Integrations: Surfacing External Data
First-party integrations follow a different pattern: instead of embedding a remote app, they index external data into per-organization search indexes and render it with native widgets.
The GitHub integration, for example, ingests pull requests, commits, and branches into dedicated indexes scoped to your organization. Ticket widgets then query those indexes by the ticket's reference to show related development activity. The integration surfaces information; it does not silently rewrite your tickets.
MCP: Pomavo for AI Agents
The MCP server exposes Pomavo's capabilities as a set of tools an AI agent can call, querying tickets, creating and updating work, managing iterations, and more. Requests authenticate with an API key bound to an organization, so an agent operates within exactly one tenant's data and permissions. This is the same surface the documentation's automation and ticketing concepts describe, made callable programmatically.
Why This Architecture
The core stays small
New capabilities arrive as plugins and integrations, so the platform doesn't grow a feature for every request.
Isolation by default
Plugins run sandboxed and communicate only through a typed, origin-checked channel.
Scoped access
Plugins and agents receive tokens scoped to a tenant and a purpose, never blanket access.